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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
