Puppet users - May 2013 - How to refer to common variables across multiple modules?

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.

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.

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.

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.