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/override$20define/puppet-users/Jb9Xr02dR7U/_LzailkL5-0J
CANT:
https://groups.google.com/forum/?fromgroups#!searchin/puppet-users/override$20define/puppet-users/SDa1F817UBA/rX-D26-q-rgJ
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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/llfl34W_EjUJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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.9Puppet 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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/oawGNZJ8C5oJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/uuS0km7K9PoJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On May 10, 8:15 am, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:> 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 ;)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 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 On Friday, May 11, 2012 8:08:52 AM UTC-5, jcbollinger wrote:> > > On May 10, 8:15 am, Jake - USPS <jacob.m.mcc...@usps.gov> wrote: > > 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 ;) > > > 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 >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/vrBJramXx7MJ. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.