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.