FAQ
We need to refer to common variables across multiple modules. For example,
our dns module, firewall module and monitoring module need knowledge of our
radius server IP address. Is the correct approach to create a 'common'
class where these variables are defined and then reference them from each
module and create a class dependancy as below. We are using a custom ENC
which outputs the class parameters.

# modules/common/manifest/init.ppclass common (
   $radius_ip,
   $fw_ip,
   $zabbix_ip,) {}
# modules/common/manifest/apache.ppclass apache (
   $fw_ip = $common::fw_ip,
   $zabbix_ip =$common::zabbix_ip,) {
   class { 'common': } ->
   class { 'apache': }}
# modules/common/manifest/maradns.ppclass maradns (
   $radius_ip = $common::radius_ip,
   $fw_ip = $common::vpn_ip,){
   class { 'common': } ->
   class { 'apache': }}
# ENC ouput---
classes:
     common:
       fw_ip: '10.50.1.1'
       radius_ip: '10.50.1.12'
       zabbix_ip: '10.50.1.11'
     apache:
     ntp:
     maradns:
environment: production


--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jcbollinger at May 3, 2013 at 1:38 pm

    On Thursday, May 2, 2013 3:54:47 PM UTC-5, rogerl...@gmail.com wrote:
    We need to refer to common variables across multiple modules. For example,
    our dns module, firewall module and monitoring module need knowledge of our
    radius server IP address. Is the correct approach to create a 'common'
    class where these variables are defined and then reference them from each
    module and create a class dependancy as below. We are using a custom ENC
    which outputs the class parameters.


    The idea of putting the shared data in a class (or classes) is very
    reasonable. You might consider, however, assigning them to classes
    specific to their purpose. For example, supposing that you will eventually
    want to manage your firewall via Puppet, you should consider whether it
    makes more sense to put the $fw_ip variable in a class associated
    specifically with that instead of in a general-purpose common class.

    It is potentially problematic, however, that you feed the shared data to
    your classes as class parameter defaults. It will probably work with the
    ENC-based setup you describe, but it has parse-order dependencies arising
    from usage of class 'common's variables by classes that themselves do
    nothing to ensure that class common has yet been evaluated. In particular,
    the chaining operators do not help: they set up client-side
    order-of-application constraints, but do not constrain compile-time
    order-of-evaluation.

    I have never been a big fan of class parameterization, and I don't see what
    it's actually doing for you here. Yes, it gives you a hypothetical ability
    to override the shared data on a per-class basis, but do you actually need
    that right now? It complicates your work, and if you don't need it now
    then there's a good chance that you're not ever going to need it. I would
    write the classes along these lines:

    class apache {
       include 'common'
       # use $common::fw_ip, etc. explicitly, as needed
    }

    Or if you want to provide for easy insertion of per-class overrides in the
    future, then it would be cheap and mostly harmless to do it this way:

    class apache {
       include 'common'
       $fw_ip = $common::fw_ip

       # use $[apache::]fw_ip, as needed
    }

    There are other alternatives, such as variations on the theme of loading
    the wanted data from an external store (e.g. hiera) instead of having the
    ENC specify them. All in all, you seem to be thinking about the right
    issues.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan White at May 4, 2013 at 12:35 am
    You might consider Top Scope [1] and/or Node Scope [2] variables.

    [1] http://docs.puppetlabs.com/puppet/3/reference/lang_scope.html#top-scope
    [2] http://docs.puppetlabs.com/puppet/3/reference/lang_scope.html#node-scope
    On May 2, 2013, at 4:54 PM, rogerlawfield@gmail.com wrote:

    We need to refer to common variables across multiple modules. For example, our dns module, firewall module and monitoring module need knowledge of our radius server IP address. Is the correct approach to create a 'common' class where these variables are defined and then reference them from each module and create a class dependancy as below. We are using a custom ENC which outputs the class parameters.

    # modules/common/manifest/init.pp
    class common (
    $radius_ip,
    $fw_ip,
    $zabbix_ip,
    ) {
    }

    # modules/common/manifest/apache.pp
    class apache (
    $fw_ip = $common::fw_ip,
    $zabbix_ip =$common::zabbix_ip,
    ) {
    class { 'common': } ->
    class { 'apache': }
    }

    # modules/common/manifest/maradns.pp
    class maradns (
    $radius_ip = $common::radius_ip,
    $fw_ip = $common::vpn_ip,
    ){
    class { 'common': } ->
    class { 'apache': }
    }

    # ENC ouput
    ---
    classes:
    common:
    fw_ip: '10.50.1.1'
    radius_ip: '10.50.1.12'
    zabbix_ip: '10.50.1.11'
    apache:
    ntp:
    maradns:
    environment: production


    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Drew Michel at May 6, 2013 at 12:55 am
    I've found that using Hiera for this type of problem work's really well.
    Hiera is integrated into Puppet 3.0+

    https://github.com/puppetlabs/hiera


    Drew

    On Thursday, May 2, 2013 4:54:47 PM UTC-4, rogerl...@gmail.com wrote:

    We need to refer to common variables across multiple modules. For example,
    our dns module, firewall module and monitoring module need knowledge of our
    radius server IP address. Is the correct approach to create a 'common'
    class where these variables are defined and then reference them from each
    module and create a class dependancy as below. We are using a custom ENC
    which outputs the class parameters.

    # modules/common/manifest/init.ppclass common (
    $radius_ip,
    $fw_ip,
    $zabbix_ip,) {}
    # modules/common/manifest/apache.ppclass apache (
    $fw_ip = $common::fw_ip,
    $zabbix_ip =$common::zabbix_ip,) {
    class { 'common': } ->
    class { 'apache': }}
    # modules/common/manifest/maradns.ppclass maradns (
    $radius_ip = $common::radius_ip,
    $fw_ip = $common::vpn_ip,){
    class { 'common': } ->
    class { 'apache': }}
    # ENC ouput---
    classes:
    common:
    fw_ip: '10.50.1.1'
    radius_ip: '10.50.1.12'
    zabbix_ip: '10.50.1.11'
    apache:
    ntp:
    maradns:
    environment: production

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 3, '13 at 1:56a
activeMay 6, '13 at 12:55a
posts4
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase