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...

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[ker nel.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_hugepage s]/Notify[vm.nr_hugepages:3]/message:
defined 'message' as 'vm.nr_hugepages:3'

I am using 2.7.9

Thanks!
Jake

On May 8, 3:47 pm, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:

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.

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.

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

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[ker nel.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_hugepage s]/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[ker nel.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_hugepage s]/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[ker nel.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_hugepage s]/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

On May 9, 2:33 pm, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:

Ok.

[...]

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

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

On May 10, 8:15 am, Jake - USPS <jacob.m.mcc...@usps.gov> wrote:

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

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