Romeo Theriault
2012-Mar-02 18:56 UTC
[Puppet Users] Best practices for excluding certain modules from certain nodes
Hi, I''m just getting started with puppet and am looking for some best practices on how to handle node and module inheritance issues. I''m planning to start using heira so want to plan my implementation around hiera specifics. Specifically, one item I can''t seem to find a clean way of dealing with is one-off nodes. For example, let''s say I want to apply a class called zabbix::agent to my whole infrastructure, so I put it in common.yaml. But then I find out there are a few nodes that for whatever reason I can''t apply this class to. Short of just not inheriting anything from common.yaml is there a clean way to say "inherit everything from common except zabbix::agent"? How are people dealing with the slight variations in their infrastructure? I realize it''s possible to code some logic into the classes for these specific one-off hosts but that seems really hackish and brittle. Thanks for any insight! -- Romeo -- 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.
Romeo Theriault
2012-Mar-02 20:12 UTC
[Puppet Users] Re: Best practices for excluding certain modules from certain nodes
On Fri, Mar 2, 2012 at 08:56, Romeo Theriault <romeo.theriault@maine.edu> wrote:> Hi, I''m just getting started with puppet and am looking for some best > practices on how to handle node and module inheritance issues. I''m > planning to start using heira so want to plan my implementation around > hiera specifics. > > Specifically, one item I can''t seem to find a clean way of dealing > with is one-off nodes. For example, let''s say I want to apply a class > called zabbix::agent to my whole infrastructure, so I put it in > common.yaml. But then I find out there are a few nodes that for > whatever reason I can''t apply this class to. Short of just not > inheriting anything from common.yaml is there a clean way to say > "inherit everything from common except zabbix::agent"? > > How are people dealing with the slight variations in their > infrastructure? I realize it''s possible to code some logic into the > classes for these specific one-off hosts but that seems really hackish > and brittle.After a bit more googling I found this informative puppet-users thread: http://groups.google.com/group/puppet-users/browse_thread/thread/6b59ae2470acfa14/810eb8671a5b3cdd which talks about creating special "disabled" classes which inherit the widely used class and set certain values to ''undef''. This seems like it''s probably the way to go since it''s the best method I''ve seen/heard of so far to deal with this.> I think a lot of shops do this by creating special "disabling" classes > for those one-off systems. To use your puppetmaster example (untested > pseudocode ahead): > class puppet::client { > file { ''/etc/puppet/puppet.conf'': > ensure => present, > source => ''puppet:///puppet/configfile'', > } > } > class puppet::client::disabled inherits puppet::client { > File[''/etc/puppet/puppet.conf''] { > ensure => undef, > source => undef, > } > } > class puppet::server { > include puppet::client::disabled > } > Now it''s safe to apply puppet::client to all your nodes, including > your puppetmaster, because the ::disabled class will override the > management of puppet.conf on the puppetmaster (which presumably > includes the puppet::server class).Anyone else dealing with this in a different way? Thanks, Romeo -- Romeo -- 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.
Justin Lloyd
2012-Mar-02 22:19 UTC
Re: [Puppet Users] Re: Best practices for excluding certain modules from certain nodes
I just dealt with something similar regarding installing puppet agent vs.
master and whether mcollective client (and thus activemq) should be
installed. However, I''m including my base class rather than inheriting
it.
So how about something like this?
# templates.pp (imported into site.pp)
class system_base ( $zabbix = true ) {
include motd # etc.
if $zabbix {
include zabbix::stuff
}
}
# nodes.pp (imported into site.pp)
node ''basic_host'' {
class { ''system_base'': }
}
node ''special_case'' {
class { ''system_base'': zabbix => false }
}
On Fri, Mar 2, 2012 at 12:12 PM, Romeo Theriault
<romeo.theriault@maine.edu>wrote:
> On Fri, Mar 2, 2012 at 08:56, Romeo Theriault
<romeo.theriault@maine.edu>
> wrote:
> > Hi, I''m just getting started with puppet and am looking for
some best
> > practices on how to handle node and module inheritance issues.
I''m
> > planning to start using heira so want to plan my implementation around
> > hiera specifics.
> >
> > Specifically, one item I can''t seem to find a clean way of
dealing
> > with is one-off nodes. For example, let''s say I want to apply
a class
> > called zabbix::agent to my whole infrastructure, so I put it in
> > common.yaml. But then I find out there are a few nodes that for
> > whatever reason I can''t apply this class to. Short of just
not
> > inheriting anything from common.yaml is there a clean way to say
> > "inherit everything from common except zabbix::agent"?
> >
> > How are people dealing with the slight variations in their
> > infrastructure? I realize it''s possible to code some logic
into the
> > classes for these specific one-off hosts but that seems really hackish
> > and brittle.
>
> After a bit more googling I found this informative puppet-users thread:
>
>
>
http://groups.google.com/group/puppet-users/browse_thread/thread/6b59ae2470acfa14/810eb8671a5b3cdd
>
> which talks about creating special "disabled" classes which
inherit
> the widely used class and set certain values to ''undef''.
This seems
> like it''s probably the way to go since it''s the best
method I''ve
> seen/heard of so far to deal with this.
>
>
> > I think a lot of shops do this by creating special
"disabling" classes
> > for those one-off systems. To use your puppetmaster example (untested
> > pseudocode ahead):
> > class puppet::client {
> > file { ''/etc/puppet/puppet.conf'':
> > ensure => present,
> > source =>
''puppet:///puppet/configfile'',
> > }
> > }
> > class puppet::client::disabled inherits puppet::client {
> > File[''/etc/puppet/puppet.conf''] {
> > ensure => undef,
> > source => undef,
> > }
> > }
> > class puppet::server {
> > include puppet::client::disabled
> > }
> > Now it''s safe to apply puppet::client to all your nodes,
including
> > your puppetmaster, because the ::disabled class will override the
> > management of puppet.conf on the puppetmaster (which presumably
> > includes the puppet::server class).
>
>
>
> Anyone else dealing with this in a different way?
>
> Thanks,
> Romeo
>
>
>
> --
> Romeo
>
> --
> 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.
>
>
--
“We don’t need to increase our goods nearly as much as we need to scale
down our wants. Not wanting something is as good as possessing it.” --
Donald Horban
--
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.
jcbollinger
2012-Mar-05 14:24 UTC
[Puppet Users] Re: Best practices for excluding certain modules from certain nodes
On Mar 2, 2:12 pm, Romeo Theriault <romeo.theria...@maine.edu> wrote:> On Fri, Mar 2, 2012 at 08:56, Romeo Theriault <romeo.theria...@maine.edu> wrote: > > [...] one item I can''t seem to find a clean way of dealing > > with is one-off nodes. For example, let''s say I want to apply a class > > called zabbix::agent to my whole infrastructure, so I put it in > > common.yaml. But then I find out there are a few nodes that for > > whatever reason I can''t apply this class to. Short of just not > > inheriting anything from common.yaml is there a clean way to say > > "inherit everything from common except zabbix::agent"? > > > How are people dealing with the slight variations in their > > infrastructure? I realize it''s possible to code some logic into the > > classes for these specific one-off hosts but that seems really hackish > > and brittle. > > After a bit more googling I found this informative puppet-users thread: > > http://groups.google.com/group/puppet-users/browse_thread/thread/6b59... > > which talks about creating special "disabled" classes which inherit > the widely used class and set certain values to ''undef''. This seems > like it''s probably the way to go since it''s the best method I''ve > seen/heard of so far to deal with this.That is one of the standard approaches to the kind of problem you describe, and it is simultaneously one of the few appropriate uses for class inheritance. The post you referenced provides a rather specific solution, however, and your description of it suggests that you may not yet see how that generalizes. In particular, 1) Overriding resource properties is the entire purpose of class inheritance. 2) A subclass can override resource properties to any value, not just undef. In fact, I think overriding to undef is unusual. 3) Although setting a resource property to undef generally means that *property* is unmanaged, that''s a very different thing from making the entire resource be unmanaged. 4) Not managing a resource (or property) is very different from managing it to an atypical state. Either might be what you want.> Anyone else dealing with this in a different way?Not I, but I can offer some alternatives anyway. Hiera provides several: A) Put an if block in Class[''zabbix-agent''] around everything else in the class body. Use hiera to look up the value controlling whether the condition is satisfied. That provides an opt-out that any node can be made to use simply by setting an appropriate value in its hiera data. B) As I recall (but have not used), hiera provides an ENC-like function whereby you can cause it to declare classes for your nodes based on class names it looks up in your data. You could use that to decide whether to apply Class[''zabbix-agent''] instead of declaring it in a class / node declaration that every node uses. Leverage hiera''s hierarchical structure. C) Instead of overriding certain resource properties in a subclass, have the erstwhile parent class use hiera to look up the wanted property values in the first place. This is a general-purpose alternative to class inheritance. 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.
Romeo Theriault
2012-Mar-06 23:51 UTC
Re: [Puppet Users] Re: Best practices for excluding certain modules from certain nodes
Thank you both for your great replies. They''ve both given me a great lead on which direction to head in. I haven''t had the time to fully flesh out how I''m going to handle this yet but I know I''ll be trying to stay away from parametrized classes for the time being. I''ll also be trying to use hiera as much as possible to handle external data and determining which classes get applied to which nodes. Thanks again for the help. Romeo On Mon, Mar 5, 2012 at 04:24, jcbollinger <John.Bollinger@stjude.org> wrote:> > > On Mar 2, 2:12 pm, Romeo Theriault <romeo.theria...@maine.edu> wrote: >> On Fri, Mar 2, 2012 at 08:56, Romeo Theriault <romeo.theria...@maine.edu> wrote: >> > [...] one item I can''t seem to find a clean way of dealing >> > with is one-off nodes. For example, let''s say I want to apply a class >> > called zabbix::agent to my whole infrastructure, so I put it in >> > common.yaml. But then I find out there are a few nodes that for >> > whatever reason I can''t apply this class to. Short of just not >> > inheriting anything from common.yaml is there a clean way to say >> > "inherit everything from common except zabbix::agent"? >> >> > How are people dealing with the slight variations in their >> > infrastructure? I realize it''s possible to code some logic into the >> > classes for these specific one-off hosts but that seems really hackish >> > and brittle. >> >> After a bit more googling I found this informative puppet-users thread: >> >> http://groups.google.com/group/puppet-users/browse_thread/thread/6b59... >> >> which talks about creating special "disabled" classes which inherit >> the widely used class and set certain values to ''undef''. This seems >> like it''s probably the way to go since it''s the best method I''ve >> seen/heard of so far to deal with this. > > > That is one of the standard approaches to the kind of problem you > describe, and it is simultaneously one of the few appropriate uses for > class inheritance. The post you referenced provides a rather specific > solution, however, and your description of it suggests that you may > not yet see how that generalizes. > > In particular, > 1) Overriding resource properties is the entire purpose of class > inheritance. > 2) A subclass can override resource properties to any value, not just > undef. In fact, I think overriding to undef is unusual. > 3) Although setting a resource property to undef generally means that > *property* is unmanaged, that''s a very different thing from making the > entire resource be unmanaged. > 4) Not managing a resource (or property) is very different from > managing it to an atypical state. Either might be what you want. > > >> Anyone else dealing with this in a different way? > > > Not I, but I can offer some alternatives anyway. Hiera provides > several: > > A) Put an if block in Class[''zabbix-agent''] around everything else in > the class body. Use hiera to look up the value controlling whether > the condition is satisfied. That provides an opt-out that any node > can be made to use simply by setting an appropriate value in its hiera > data. > > B) As I recall (but have not used), hiera provides an ENC-like > function whereby you can cause it to declare classes for your nodes > based on class names it looks up in your data. You could use that to > decide whether to apply Class[''zabbix-agent''] instead of declaring it > in a class / node declaration that every node uses. Leverage hiera''s > hierarchical structure. > > C) Instead of overriding certain resource properties in a subclass, > have the erstwhile parent class use hiera to look up the wanted > property values in the first place. This is a general-purpose > alternative to class inheritance. > > > 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. >-- Romeo -- 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.