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. > > 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. > 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. > > > 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"....) 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. 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.... Have fun, udo. -- :: udo waechter - r...@zoide.net :: N 52º16'30.5" E 8º3'10.1" :: genuine input for your ears: http://auriculabovinari.de :: your eyes: http://ezag.zoide.net :: your brain: http://zoide.net --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
