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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
