Can you override a define parameter

97 views
Skip to first unread message

Jake - USPS

unread,
May 8, 2012, 4:47:26 PM5/8/12
to puppet...@googlegroups.com
Should I be able to override a parameter in a define?  I've been searching the group and found answers both saying you can and can't

CAN:

CANT:

So here is what I have ...

Defined in a class:
class oracle_db {
      etc_sysctl_conf { 'kernel.shmall':
        value => '1',
      }
}

define oracle_db::etc_sysctl_conf ( $attr = $name, $value ) {
  notify{"${attr}:${value}": }
}

Then override with another class:
class oracle_db::hugepages inherits oracle_db {
  Etc_sysctl_conf['kernel.shmall'] {
    value => '2',
  }
  etc_sysctl_conf { "vm.nr_hugepages":
    value => '3';    
  }
}

And get:
hostA:~ # puppet agent --test | grep -e shmall -e hugepage
notice: kernel.shmall:1
notice: /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:1]/message: defined 'message' as 'kernel.shmall:1'
notice: vm.nr_hugepages:3
notice: /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message: defined 'message' as 'vm.nr_hugepages:3'

I am using 2.7.9

Thanks!
Jake

jcbollinger

unread,
May 9, 2012, 9:15:36 AM5/9/12
to Puppet Users


On May 8, 3:47 pm, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:
> Should I be able to override a parameter in a define?  I've been searching
> the group and found answers both saying you can and can't
>
> CAN:https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/ov...
>
> CANT:https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/ov...


Those two threads look consistent to me, though one of the responses
to the second is wrong. The cases are similar: a class declares an
instance of a defined type, and that defined type instance declares a
resource of a built-in type. It is possible for a subclass to
override the properties of the defined type instance, but not
(directly) the properties of the resources declared by the defined
type.

That showcases the fact that defined type instances are bona fide
resources. People sometimes mistake type definitions to be a Puppet
variation on macros. That kind of thinking leads to all kinds of
wrong expectations, among them that a class should be able to override
properties of resources declared by a defined type instance, as the
OPs in those threads supposed. That does not appear to be what you
are doing.


> So here is what I have ...
>
> Defined in a class:
> class oracle_db {
>       etc_sysctl_conf { 'kernel.shmall':
>         value => '1',
>       }
>
> }
>
> define oracle_db::etc_sysctl_conf ( $attr = $name, $value ) {
>   notify{"${attr}:${value}": }
>
> }
>
> Then override with another class:
> class oracle_db::hugepages inherits oracle_db {
>   Etc_sysctl_conf['kernel.shmall'] {
>     value => '2',
>   }
>   etc_sysctl_conf { "vm.nr_hugepages":
>     value => '3';
>   }
>
> }


That should be fine. In addition, however -- and forgive me for
stating the obvious -- you do need to be sure to actually declare the
subclass on the target node.


> And get:
> hostA:~ # puppet agent --test | grep -e shmall -e hugepage
> notice: kernel.shmall:1
> notice:
> /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:1]/message:
> defined 'message' as 'kernel.shmall:1'
> notice: vm.nr_hugepages:3
> notice:
> /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message:
> defined 'message' as 'vm.nr_hugepages:3'
>
> I am using 2.7.9


Puppet should issue a catalog compilation error if one of the classes
for the node attempts to perform a resource property override that is
not permitted. I can't speak to the Notifies in your output, because
they're not represented in the manifest fragments you posted. Also,
although the debug log output by 'puppet agent --test' will indicate,
I think, whether class oracle_db::hugepages is included on the node, I
can't tell from the filtered log output above whether it has been.


John

Jake - USPS

unread,
May 9, 2012, 3:33:48 PM5/9/12
to puppet...@googlegroups.com
John,

Thanks so much for the response.  It sounds to me like what I am trying to do should be working, but because you can not verify a couple things you can't comment on if I've implemented it correctly or not.

So firstly, I am including the class 'oracle_db::hugepages'.  This is assigned to the system from an ENC and is how resource 'Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3' is getting applied to the system.

Next, the notify is in my code fragment, in the define 'oracle_db::etc_sysctl_conf'.

oracle_db/manifests/init.pp:

class oracle_db {
      etc_sysctl_conf { 'kernel.shmall':
        value => '1',
      }
}

define oracle_db::etc_sysctl_conf ( $attr = $name, $value ) {
  notify{"${attr}:${value}": }
}

And I'll just post hugepages again quick ...

oracle_db/manifests/hugepages.pp

class oracle_db::hugepages inherits oracle_db {
  Etc_sysctl_conf['kernel.shmall'] {
    value => '2',
  }
  etc_sysctl_conf { "vm.nr_hugepages":
    value => '3';    
  }
}

So what I would expect is on my system that has BOTH oracle_db and oracle_db::hugepages assigned to it (same results when only hugepages assigned) that I would get the following output:

notice: kernel.shmall:2
notice: /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:2]/message: defined 'message' as 'kernel.shmall:2'
notice: vm.nr_hugepages:3
notice: /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message: defined 'message' as 'vm.nr_hugepages:3'

But instead get the following:

notice: kernel.shmall:1
notice: /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:1]/message: defined 'message' as 'kernel.shmall:1'
notice: vm.nr_hugepages:3
notice: /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message: defined 'message' as 'vm.nr_hugepages:3'
 
And here is some unfiltered output:

hostA:~ # puppet agent --test 
info: Retrieving plugin
info: Loading facts in usps_bu_eth
info: Loading facts in usps_puppet_db_server
info: Loading facts in usps_syslog_client_ip
info: Loading facts in usps_puppet_master_host
info: Loading facts in hcs_service
info: Loading facts in packages
info: Loading facts in usps_patch_bundle
info: Loading facts in usps_bu_net_zone
info: Loading facts in memorysize
info: Loading facts in usps_puppet_basedir
info: Loading facts in usps_os_dist
info: Loading facts in usps_is_dmz
info: Loading facts in network
info: Loading facts in usps_os_version
info: Loading facts in jumpver_facts
info: Loading facts in usps_bu_macaddress
info: Loading facts in usps_patch_repo
info: Loading facts in usps_public_int
info: Loading facts in usps_patch_status
info: Loading facts in concat_basedir
info: Loading facts in usps_bu_int
info: Loading facts in usps_is_ctm_server
info: Loading facts in usps_is_puppet_master
info: Loading facts in usps_puppet_env
info: Loading facts in usps_puppet_ca_server
info: Loading facts in usps_puppet_report_server
info: Loading facts in usps_bu_net
info: Loading facts in usps_puppet_is_ca
info: Loading facts in usps_bu_ip
info: Loading facts in usps_patch_env
info: Loading facts in usps_bootloader
info: Loading facts in usps_patch_date
info: Loading facts in usps_bu_eth
info: Loading facts in usps_puppet_db_server
info: Loading facts in usps_syslog_client_ip
info: Loading facts in usps_puppet_master_host
info: Loading facts in hcs_service
info: Loading facts in packages
info: Loading facts in usps_patch_bundle
info: Loading facts in usps_bu_net_zone
info: Loading facts in memorysize
info: Loading facts in usps_puppet_basedir
info: Loading facts in usps_os_dist
info: Loading facts in usps_is_dmz
info: Loading facts in network
info: Loading facts in usps_os_version
info: Loading facts in jumpver_facts
info: Loading facts in usps_bu_macaddress
info: Loading facts in usps_patch_repo
info: Loading facts in usps_public_int
info: Loading facts in usps_patch_status
info: Loading facts in concat_basedir
info: Loading facts in usps_bu_int
info: Loading facts in usps_is_ctm_server
info: Loading facts in usps_is_puppet_master
info: Loading facts in usps_puppet_env
info: Loading facts in usps_puppet_ca_server
info: Loading facts in usps_puppet_report_server
info: Loading facts in usps_bu_net
info: Loading facts in usps_puppet_is_ca
info: Loading facts in usps_bu_ip
info: Loading facts in usps_patch_env
info: Loading facts in usps_bootloader
info: Loading facts in usps_patch_date
Could not retrieve macaddress_eth2: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth3: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth8: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth9: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth12: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth13: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth14: undefined method `[]' for nil:NilClass
Could not retrieve macaddress_eth15: undefined method `[]' for nil:NilClass
info: Caching catalog for hostA
info: Applying configuration version '1336591539'
notice: kernel.shmall:1
notice: /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:1]/message: defined 'message' as 'kernel.shmall:1'
notice: vm.nr_hugepages:3
notice: /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message: defined 'message' as 'vm.nr_hugepages:3'
notice: Finished catalog run in 17.88 seconds

Let me know if I misunderstood and am still missing something to show what I am trying to do and how it doesn't seem to be working.

Thanks again,
Jake

jcbollinger

unread,
May 10, 2012, 8:57:29 AM5/10/12
to Puppet Users


On May 9, 2:33 pm, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:
> John,
>
> Thanks so much for the response.  It sounds to me like what I am trying to
> do should be working, but because you can not verify a couple things you
> can't comment on if I've implemented it correctly or not.
>
> So firstly, I am including the class 'oracle_db::hugepages'.  This is
> assigned to the system from an ENC and is how resource
> 'Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3'
> is getting applied to the system.


Ok.


> Next, the notify is in my code fragment, in the define
> 'oracle_db::etc_sysctl_conf'.
>
> oracle_db/manifests/init.pp:
>
> class oracle_db {
>       etc_sysctl_conf { 'kernel.shmall':
>         value => '1',
>       }
>
> }
>
> define oracle_db::etc_sysctl_conf ( $attr = $name, $value ) {
>   *notify{"${attr}:${value}": }*
>
> }
>
> And I'll just post hugepages again quick ...
>
> oracle_db/manifests/hugepages.pp
>
> class oracle_db::hugepages inherits oracle_db {
>   Etc_sysctl_conf['kernel.shmall'] {
>     value => '2',
>   }
>   etc_sysctl_conf { "vm.nr_hugepages":
>     value => '3';
>   }
>
> }
>
> So what I would expect is on my system that has BOTH oracle_db and
> oracle_db::hugepages assigned to it (same results when only hugepages
> assigned) that I would get the following output:
>
> notice: kernel.shmall:*2*
> notice:
> /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:
> *2*]/message: defined 'message' as 'kernel.shmall:*2*'
> notice: vm.nr_hugepages:3
> notice:
> /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message:
> defined 'message' as 'vm.nr_hugepages:3'
>
> But instead get the following:
>
> notice: kernel.shmall:*1*
> notice:
> /Stage[main]/Oracle_db/Oracle_db::Etc_sysctl_conf[kernel.shmall]/Notify[kernel.shmall:
> *1*]/message: defined 'message' as 'kernel.shmall:*1*'
> notice: vm.nr_hugepages:3
> notice:
> /Stage[main]/Oracle_db::Hugepages/Oracle_db::Etc_sysctl_conf[vm.nr_hugepages]/Notify[vm.nr_hugepages:3]/message:
> defined 'message' as 'vm.nr_hugepages:3'
>
> And here is some unfiltered output:
[...]

I think your expectations are correct. Just in case, however, I
recommend that you use fully-qualified names throughout your
manifests, and that you lay out classes and definitions as expected by
the autoloader. In particular:

oracle_db/manifests/hugepages.pp
====
class oracle_db::hugepages inherits oracle_db {
Oracle_db::Etc_sysctl_conf['kernel.shmall'] {
value => '2',
}
oracle_db::etc_sysctl_conf { "vm.nr_hugepages":
value => '3';
}
}
====

and move the definition to its own file:

oracle_db/manifests/etc_sysctl_conf.pp
====
define oracle_db::etc_sysctl_conf ( $attr = $name, $value ) {
*notify{"${attr}:${value}": }*
}
====

I would have expected Puppet to throw a compilation error if it
couldn't resolve the resource type, but it would be wise to cover that
possibility anyway. You could also try restarting the master to
ensure that it recompiles the catalog. If none of that works then it
looks like a regression to me.


John

Jake - USPS

unread,
May 10, 2012, 9:15:54 AM5/10/12
to puppet...@googlegroups.com
John,

I've made everything fully qualified as you suggested, and also split the define to its own file as you suggested.  I've restarted my master as you suggested.  I'm still running into the issue.  :(

I think now I will try the latest version of puppet to see if this is something that was fixed.  If not then I'll go and try older versions of puppet and see if I can find where it stopped working (unless you have some more ideas on things to try ;)

Thanks for all your help!
Jake

jcbollinger

unread,
May 11, 2012, 9:08:52 AM5/11/12
to Puppet Users
I think it would be relevant to add the information you provided on
the bug tracker, that the problem seems to be associated with your
split of the class declarations between site.pp and an ENC. Although
Puppet allows it, I think such a split is unwise -- if you're going to
use an ENC then go all the way and rely on it completely.

This does still look like a bug to me, but I'm no longer confident
that it's a regression. Whether it is or not, your best way forward
may be to either have class oracle_db also assigned via your ENC (when
it is assigned at all), or else move the responsibility for
oracle_db::hugepages out of your ENC into regular manifests.


John

Jake - USPS

unread,
May 11, 2012, 9:37:37 AM5/11/12
to puppet...@googlegroups.com
John,

Sorry for not updating this post with the additional details.  And I agree with you on everything you just said (probably not regression, should work, shouldn't be doing what I'm doing ...) and I plan on figuring that out today ... as I need a workaround for this issue now.  ;)

And also if others wanted to know the bug I filed: https://projects.puppetlabs.com/issues/14399

Thanks again for your help with this!!
Jake
Reply all
Reply to author
Forward
0 new messages