hello,
> > This might be a start to some sort of evolved smart node idea (tha we > > could stick in Dashboard and also build a CLI tool to) that could > > support the concept of variable inheritance. So not just define what > > machines are webservers (rather than what webservers are what machine) > > but use similar regexen (or another system of groups) to classify what > > machines live in what areas -- and blend the two groups together. > > > > Dan Bode mentions he sees several logical groups here -- there's what > > type of a machine you have, whether it's a stage/prod machine, and > > what location (datacenter) it is in (i.e. what is the machine's > > geographic location). Some variables may come from one or more of > > those sources, and they can have some basic defaults. (This is > > somewhat similar to Cobbler's "blender" inheritance for groups of > > things... allowing extension of arrays and adding keys to hashes, or > > overriding of scalars, as we evaluate the group orders. The > > location groups and the classification groups would not need to be > > chained (i..e one a parent of another) but we'd want to support the > > idea of inherited subgroups (acme-datacenter is a subset of > > us-datacenters is a subset of datacenters). Apologies if I'm being > > confusing :) Did you look at extlookup? Cos thats what it does. > I don't want to sound a fanboy or one of Volcane's minions, but I think > his idea is spot on for this kind of thing. If it had LDAP/other DB > support it would be even more ridiculously awesome. At the base of > this problem, your base solution is you just need a function that can look > up arbitrary data. Hostname can come into play, but with extlookup you > can choose an order of precedence (IE overriding: hostname.csv trumps > domain.csv or vice versa and it's all configurable). I use CSV files > cause I am lazy, it is easy, and my environment is small. Someone at > $FORTUNE500 could use LDAP if the tool was extended slightly. Julian Simpson is working on making the backends pluggable so we should have something soon. Foreman already has integration on its side for extlookup (it's in trunk or something) as soon as Julian and I finish making the backend pluggable it will be able to integrate easily into foreman. > As I recall however, extlookup.rb is not included in mainline puppet > because Luke disagrees with the implementation I think. Could be > wrong here. Best to ask him. I deploy it as part of my deploy:cold cap task > for new masters. Luke has said if we make it pluggable and make tests he'd be open to including it in base so we're working on that. > The point is, a tool like this should be in puppet, extlookup.rb > right now kicks a lot of ass. RL can do what they want obviously, but they > should look at this tool. there's a ticket for something like this already, I've highlighted all what extlookup does so hopefully we'll get there one way or the other! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
