On Thu, Sep 1, 2011 at 10:30 PM, Matt Moor <m...@imprecise.org> wrote:
> 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<http://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/<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, > > Hi Matt. :) Unfortunately, using the FQDN to determine the class of server here isn't feasible. The DNS namespace is pretty flat. As for the helper file option, I can add a variable to the node definition, which is what I was hoping to do. I can then template the value, and write it to a file on the target. However, at this point, using a custom fact to retrieve the value from the local O/S seems a bit heavy handed. Maybe that's what I'll have to end up using. At the end of the day, this all seems to be a limitation with mcollective. It can only read facts from one source, either facter or a yaml file. I believe facter is the current source, and people have written scripts that rely on that. I can write a custom fact, but.... then the issue becomes that I don't know if it's possible for a custom fact written in ruby and dropped into $module/lib/puppet can access variables defined in the node. Doug. -- 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.
