On 2/09/11 3:03 PM, Douglas Garstang wrote:
I really appreciate your reply, but I've inherited a mess that isn't
easy to fix, and the most appropriate solution for right now isn't
always the "best" solution. When the boss says "GET IT DONE", you
don't have time to refactor someone elses mess and do it the right
way. I try and make my questions as specific as possible so that I can
get options that are as specific to the problem at hand as possible.
Class is an unbelievably overloaded term, but I'm gathering you mean it
in the context of identifying a group of machines, and will assume so
for the purposes of this post. I've hacked around this problem a couple
of ways in the past:
- Derive the class from the FQDN
Previous organisations have had FQDN structures like
sitename-app-01.staging.mycompany.net, and I've just written a simple
fact to extract the class from that; e.g. staging-app. I don't really
recommend this approach, as it can be brittle, it overloads DNS, and
it's not very granular. But it worked.
- Use a "helper" file
If you've got the node classification available on the puppetmaster
(e.g. node foo { $class=abc }), I've used a template to write a file
with the class details out somewhere useful like
/etc/mycompany/machine_class.
This guy seems to have taken this idea and run with it:
http://nuknad.com/2011/02/11/self-classifying-puppet-nodes/
If I was wanting to do this the "right" way, I'd be looking at hooking
mcollective up to an external node classifier in some way - that way
both Puppet and MCollective are referencing the same source of "truth".
No tips on how to actually to do this - it's just where I'd start looking.
Cheers,
Matt
--
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.
