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

Search Discussions

  • Jcbollinger at May 9, 2012 at 1:15 pm

    On May 8, 3:47 pm, Jake - USPS 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

    --
    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.
  • Jake - USPS at May 9, 2012 at 7:33 pm
    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.
  • Jcbollinger at May 10, 2012 at 12:57 pm

    On May 9, 2:33 pm, Jake - USPS 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.
  • Jake - USPS at May 10, 2012 at 1:16 pm
    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.
  • Jcbollinger at May 11, 2012 at 1:09 pm

    On May 10, 8:15 am, Jake - USPS 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.
  • Jake - USPS at May 11, 2012 at 1:37 pm
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 8, '12 at 8:47p
activeMay 11, '12 at 1:37p
posts7
users2
websitepuppetlabs.com

2 users in discussion

Jake - USPS: 4 posts Jcbollinger: 3 posts

People

Translate

site design / logo © 2022 Grokbase