On Jan 30, 2009, at 3:40 AM, udo waechter wrote: > > Hello, > On 29.01.2009, at 22:55, James Turnbull wrote: > >> >> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e. >> network -> interface -> ipaddress. > This would be a great thing to have. Additionally it would be cool to > have automatic true/false values for such namespaces, so: > > network would evaluate to "true" if there is at least one instance of > interface. > > network -> interface > I'm not so sure what the exact benefit of this would be, but somehow I > feel this could be useful. Additionally I gues the location of this > would rather be in puppet, i.e. how it interprets such namespaces.
That's the big question - how does Puppet use the namespaces. One simple but stupid solution is to s/::/_/; e.g., $network::interface would become $network_interface. Another, probably equally stupid solution is to automatically fill the facts into namespaces in puppet, but this would collide with, e.g., a 'network' module. A third, maybe less stupid, option, is to only support them relative to nodes: you could have non-namespaced facts anywhere, but namespaced facts would need to be prefixed: $node::network::interface et al. Any other ideas? >> 3. Additional collection mechanisms, for example the ability to >> specify a fact file, /etc/facter.conf, containing fact name=value >> pairs. > This would be great. One could then define something like inventory > numbers and places for nodes. > > Additionally facter could issue a call to a external URL to get > additional facts (like room, admin-email, and such) > so: http://hostname/getfacts=$fqdn or so would return a yaml file with > additional facts. This would make integration with external inventory- > management tools easier. Hmm. That kind of integration should really happen through an external node tool, rather than facter, IMO. > >> 4. A more Ruby DSL for facts > I'm not so sure what this means, but ruby is a great language to write > facts in. Basically, make the ruby code for defining facts both simpler and more "rubyish". The current syntax is verbose, clumsy, and not especially aesthetically appealling. Check the ShadowFacter examples for much prettier versions. > >> >> >> If you have additional ideas/requirements/issues/comments we'd >> welcome >> feedback. > Maybe it would be great to add additional attributes to namespaces. > Something like public/private, where private facts would be shown only > to certain users (maybe this access rules can be defined in > facter.conf) > This feature would be very userful when one tries to write a gui for > host's facts. > We have a very simple drupal plugin which shows the facts from our > nodes. here we explicitly need to configure the facts that are > accessible to all (cpu, memory, diskspace and such) and those that are > available only to administrative users (all other, like serialnumber, > inventorynumber, "owner"....) I could see supporting tags on facts, and then having your system use these tags to set authorization, but I hope Facter never acquires this level of functionality on its own. > > Maybe have an external fact-repository that facter could query and > synchronize with? Currently this is achieved via puppet. I guess that > this functionality could be put into facter. This way the tool becomes > less dependatn on puppet. Again, here you'd need to add file-serving functionality to Facter, which seems like a bridge too far. > > In general I think that facter should be kept as simple as possible. > Too much complexity (namespaces could be one of those cases) could > make it difficult to use facts in puppet. > Also, I think that it is very important that facter should be as > stable as possible. If one relies very much on facts (in puppet) it > would not be cool if facts change often. > We do have this in our network where we have FreeBSD, Ubuntu, Debian > and Darwin. When the operatingsystem fact changed from debian to > ubuntu on ubuntu whe had to go through a lot of manifests and classes > to adapt those to the new situation. But this is not so much of a > problem since it is a one-time change. Iff the fact does not change > back.... I agree on the stability, and we're going to make sure that all of this work will be as stable as possible, both in values and interface. One of the things I really like about ShadowFacter is that the interface is 100% backward compatible. Of course, we'll break backward compatibiity at some point, but we should have a clean upgrade path. -- SELF-EVIDENT, adj. Evident to one's self and to nobody else. -- Ambrose Bierce --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
