Puppet users - Jul 2011 - Testing if a puppet class is going to be installed

In a bunch of my templates and manifests, I need to have logic which
depends on whether or not a particular (other) puppet class is going
to be installed on the machine.

For example, for setting up the proper nagios monitors, you''d want to
say something like "if this machine has the apache class, then
configure apache monitoring"  It''s not feasible I think to put
this
logic in the "apache" class, since you''d have to have a way
to build
up the nagios config file from parts contained in many classes which
sometimes are installed together.

Is there a function I can call, or could you provide some advice on
how to approach writing such a function, which will tell me that the
machine the catalog is being compiled for also has a particular class
as part of the catalog?

Currently, I''m stuck writing templates and manifests which have a lot
of "if the hostname matches this regex, or if the fqdn matches this
regex..."  since classes are applied by fqdn ultimately, however, this
is growing unmanageable as we''re moving to a more dynamic system of
creating machines and assigning more arbitrary names to machines using
an external nodes store...

Without this feature, we''re still stuck in many cases having to commit
changes to the puppet repository when we make machines and can''t make
the jump to being fully automated machine creation with arbitrary host
names.  Additionally, IMO, it makes it very difficult to understand
many manifests and templates with all the special casing for machine
names, instead of asking about installed classes.

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

''defined'' might be what you are after ... something like:

class foo {
}

class { "foo":
}

if defined(Class["foo"]) {
  notice("foo is defined")
} else {
  notice("foo is not defined")
}

When you comment out the class { "foo": } then the expression results
in a negative.

ken.

On Thu, Jul 7, 2011 at 5:26 PM, Keith Minkler <kminkler@gmail.com>
wrote:
> In a bunch of my templates and manifests, I need to have logic which
> depends on whether or not a particular (other) puppet class is going
> to be installed on the machine.
>
> For example, for setting up the proper nagios monitors, you''d want
to
> say something like "if this machine has the apache class, then
> configure apache monitoring"  It''s not feasible I think to
put this
> logic in the "apache" class, since you''d have to have a
way to build
> up the nagios config file from parts contained in many classes which
> sometimes are installed together.
>
> Is there a function I can call, or could you provide some advice on
> how to approach writing such a function, which will tell me that the
> machine the catalog is being compiled for also has a particular class
> as part of the catalog?
>
> Currently, I''m stuck writing templates and manifests which have a
lot
> of "if the hostname matches this regex, or if the fqdn matches this
> regex..."  since classes are applied by fqdn ultimately, however, this
> is growing unmanageable as we''re moving to a more dynamic system
of
> creating machines and assigning more arbitrary names to machines using
> an external nodes store...
>
> Without this feature, we''re still stuck in many cases having to
commit
> changes to the puppet repository when we make machines and can''t
make
> the jump to being fully automated machine creation with arbitrary host
> names.  Additionally, IMO, it makes it very difficult to understand
> many manifests and templates with all the special casing for machine
> names, instead of asking about installed classes.
>
> --
> 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.
>
>
-- 
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.

Hi Keith,

On Jul 7, 5:26 pm, Keith Minkler <kmink...@gmail.com>
wrote:
> In a bunch of my templates and manifests, I need to have logic which
> depends on whether or not a particular (other) puppet class is going
> to be installed on the machine.
This use case comes up a lot. There are some functions but
historically they have not been reliable due to Puppet''s random parse
order for resources and classes. Have a look at the tagged() function
- tests if a given tag is set, and the defined() function - tests
whether a resource/class has been defined or not (not the same as
tagged).

With the latest versions of Puppet coming out though I remember
reading that one of the focuses was to make Puppet''s parse order
static rather than random, so it makes the use of these functions a
little more friendly. You could always try use run stages too.
> For example, for setting up the proper nagios monitors, you''d want
to
> say something like "if this machine has the apache class, then
> configure apache monitoring"  It''s not feasible I think to
put this
> logic in the "apache" class, since you''d have to have a
way to build
> up the nagios config file from parts contained in many classes which
> sometimes are installed together.
Example42 put monitoring into their service oriented classes, like
apache::monitor, take a look at how it works there:

https://github.com/example42/puppet-modules/blob/master/apache/manifests/monitor.pp

If all your classes define their own monitoring requirements you can
then use some other module to bring everything together for your
monitoring solution.

Another alternative is to use stored configs and write something to
query the resources on each node and build the monitoring
configuration yourself. The most amount of work but the most flexible.
> Is there a function I can call, or could you provide some advice on
> how to approach writing such a function, which will tell me that the
> machine the catalog is being compiled for also has a particular class
> as part of the catalog?
One dodgy way would be to parse /var/lib/puppet/classes.txt, however
that would only capture classes for the previous run.

Since all classes are "known" at the time that the catalog begins to
be apply, there might be some snippet of Ruby you could use to query
what classes are set and use that in a module too, but that''s one for
the Ruby devs.
> Currently, I''m stuck writing templates and manifests which have a
lot
> of "if the hostname matches this regex, or if the fqdn matches this
> regex..."  since classes are applied by fqdn ultimately, however, this
> is growing unmanageable as we''re moving to a more dynamic system
of
> creating machines and assigning more arbitrary names to machines using
> an external nodes store...
If you''re using an ENC to classify your nodes, don''t you then
know
what services are on each node there, and so could then get an idea of
what you need to monitor from your ENC and not your Puppet catalogs?
> Without this feature, we''re still stuck in many cases having to
commit
> changes to the puppet repository when we make machines and can''t
make
> the jump to being fully automated machine creation with arbitrary host
> names.  Additionally, IMO, it makes it very difficult to understand
> many manifests and templates with all the special casing for machine
> names, instead of asking about installed classes.
Hope that helps a bit,

-Luke

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

Thanks Luke,
> This use case comes up a lot. There are some functions but
> historically they have not been reliable due to Puppet''s random
parse
> order for resources and classes.
This is the trouble I had with the defined() function, so I had given
up on it, since it was not returning in a reliable way.
> With the latest versions of Puppet coming out though I remember
> reading that one of the focuses was to make Puppet''s parse order
> static rather than random, so it makes the use of these functions a
> little more friendly. You could always try use run stages too.
maybe... however this would still sort of have the same troubles as
random, if you need to test against classes which have not been
"processed" yet, but are still "assigned to the node".
> If all your classes define their own monitoring requirements you can
> then use some other module to bring everything together for your
> monitoring solution.
If I''m understanding this correctly, this would involve custom
resource types to pull together the parts of the file, such as one for
"parts of the file" which all notify a "things which compiles
them
together".

I used the monitoring example, but there are examples of where a
simple "does this server get X class" would help to clean things up in
my puppet repo, I''m not sure I want to go the route of making
something like this for each of those instances, and was hoping for a
very generic solution.
> One dodgy way would be to parse /var/lib/puppet/classes.txt, however
> that would only capture classes for the previous run.
I hadn''t considered this, it would have to be part of a custom fact
though, since I would need the information on the puppetmaster when
processing the catalog (the template renders also happen server side,
right?)... there is the client_yaml directories on the server though
that could provide this though...
> Since all classes are "known" at the time that the catalog begins
to
> be apply, there might be some snippet of Ruby you could use to query
> what classes are set and use that in a module too, but that''s one
for
> the Ruby devs.
I''d like to explore this solution a bit more.  I''ve already
added some
custom parser functions and custom facts, so I''m not too worried about
the ruby involved if someone could point me into a better direction
than trying to grep through the puppet code for the right hooks ;)
> If you''re using an ENC to classify your nodes, don''t you
then know
> what services are on each node there, and so could then get an idea of
> what you need to monitor from your ENC and not your Puppet catalogs?
Yes and no... generally what''s stored in the external nodes are more
high-level classes which include a bunch of other classes.  The rules
are usually against the "bunch of other classes".  I may be able to
use this as a starting point though if I could generate a hierarchy of
includes (although some classes are also conditionally included).
> Hope that helps a bit,
Thanks for the response, seems like my current best option to
investigate is to see if I can use some of the internal puppet classes
to get details about the entire catalog.

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

On Thu, Jul 7, 2011 at 2:10 PM, Keith Minkler <kminkler@gmail.com> wrote:
> Thanks Luke,
>
> > This use case comes up a lot. There are some functions but
> > historically they have not been reliable due to Puppet''s
random parse
> > order for resources and classes.
>
> This is the trouble I had with the defined() function, so I had given
> up on it, since it was not returning in a reliable way.
>

Tagged() tends to be more reliable but less complete. (And I think it
requires an external node classifier..?)

If the machine has ''webserver'' in the yaml from the ENC, and
webserver
includes apache, then in theory defined will be true for both apache and
webserver. Tagged will only be true for webserver, but thats often enough
(at least in our setup, although it is still something I am trying to get
rid of..) And it should be true every time, regardless of parsing order.

Also, you can include classes/tags in the yaml that don''t exist without
causing any issues. (For example, we use a ''nomonitor'' class
to bypass all
the icinga modules cleanly..)

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

Did I miss the part where it was determined that having one class
require the other one(s) didn''t work?

* Disconnect <dc.disconnect at gmail.com> [2011/07/07
14:57]:
> On Thu, Jul 7, 2011 at 2:10 PM, Keith Minkler <kminkler@gmail.com>
wrote:
> > > This use case comes up a lot. There are some functions but
> > > historically they have not been reliable due to Puppet''s
> > > random parse order for resources and classes.
> >
> > This is the trouble I had with the defined() function, so I had
> > given up on it, since it was not returning in a reliable way.
> 
> Tagged() tends to be more reliable but less complete. (And I think
> it requires an external node classifier..?)
-- 
Half of the harm that is done in this world is due to people who want
to feel important. They don''t mean to do harm but the harm does not
interest them.
    -- T.S. Eliot

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

This need is why we''ve modified the default ACL in 2.7.x to allow you
to
retrieve your own node definitions easily.

http://groups.google.com/group/puppet-dev/browse_thread/thread/fba16b6f26015daa

"If you add a rule like this to puppet 2.7.0rc1 in auth.conf

path ~ ^/node/([^/]+)$
method find
allow $1

then nodes are able to find their own node definitions from the master
like this:

$ puppet node find <certname> --terminus rest --server <servername>

This is really useful, as it allows you to do things from the node
like find out what environment/classes/parameters an ENC is going to
define for you. This would allow us to modify the configurer face to
work out what environment you are going to be assigned before you do
any pluginsync."

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

On Thu, 07 Jul 2011, Keith Minkler wrote:
> For example, for setting up the proper nagios monitors, you''d 
> want to say something like "if this machine has the apache 
> class, then configure apache monitoring" It''s not feasible I 
> think to put this logic in the "apache" class, since
you''d
> have to have a way to build up the nagios config file from 
> parts contained in many classes which sometimes are installed 
> together.
I would probably use a concatenated file for this.  Define a 
function in the nagios class that means "please monitor this 
service using these parameters", and let the apache class call 
that.  Behind the scenes, the nagios class would use concat and 
concat::fragment to do the work.

See 
<http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php>
for an example.

--apb (Alan Barrett)

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