+1 for this. I think that it is vital to make facter (the core) as fast as possible. If it is really easy to crate new facts in arbitrary languages (I'm looking forward to this :), then facter already does enough of forking. Internally, I would represent facts as that as what they are... Strings and/or Hashes.
An exporter class could then export all facts to whatever format is implemented. udo. On 19.02.2009, at 01:13, Nigel Kersten wrote: > > Given the pretty poor performance of yaml is it really an ideal choice > for ibternal representations? > > The benefit of yaml is that it is human readable. I don't think it > makes sense internally. > > My 2c. > > > > On 2/18/09, Andreas Rogge <a.ro...@solvention.de> wrote: >> Am Donnerstag, den 05.02.2009, 00:08 -0600 schrieb Luke Kanies: >>> On Jan 30, 2009, at 6:10 AM, Mike Pountney wrote: >>> >>>> I like this idea, but how would it work in both facter output >>>> (would >>>> it force us to use a rich output format for instance?) and puppet >>>> itself? >>> >>> This is still undecided; any recommendations? >> >> Use YAML for the internal representation and make output pluggable. >> YAML >> to XML and JSON is rather trivial, LDIF and other formats may >> require a >> bit more work. >> I would not implement anything that's not simple text output. >> >>>> >>>> If this effectively adds [something akin to] hash support to the >>>> puppet language then it's a brilliant idea. >>> >>> Facter and Puppet's use of Facter would need to iterate a bit >>> separately. Rich data needs to be added to Puppet, but it's kind >>> of a >>> different question. >>> >>> At the least, we can support rich data in Facter before Puppet can >>> use >>> it, and Puppet could probably be modified to use it pretty easily, >>> at >>> this point. >> >> I also think we need a way to return data structures as facts. Using >> them in puppet is one big thing, but facter can also help in >> different >> cases, too. (We plan to feed out inventory with data from facter). >> >>>> >>>> XML would be useful at our end. Having a mechanism to easily >>>> write new >>>> output formats (with a plugin architecture?) would be good. >>> >>> I expect some kind of simple plugin system would be used; the output >>> formats would all be ridiculously simple, though. >> >> As I already said: I'd use YAML for the internal representation. >> Output >> modules would be filters that do YAML2whatever. >> >>> >>>>>>> 3. Additional collection mechanisms, for example the ability to >>>>>>> specify a fact file, /etc/facter.conf, containing fact >>>>>>> name=value >>>>>>> pairs. >>>>>> >>>>>> /etc/factor.d ? >>>>> >>>>> That's a better idea than facter.conf I think - thanks. >> >> I guess we might want to have more than one directory in the long >> term. >> Currently there are "builtin" facts and facts delivered through >> puppet. >> >> I think there should be a search path for facter to look for facts. >> This >> should, of course, contain the "builtin" facts and should be >> changeable >> by an application using facter (i.e. puppet). >> IMO that path should at least contain a directory for site-specific >> facts, a directory where packages can put their facts and maybe a >> directory for the system administrator. >> >>>> >>>> With a simple /etc/factor.d/fact-name file containing a fact value? >>> >>> There are basically three choices here, from what I see: >>> >>> * A file containing a simple value >>> >>> * An executable file that produces a value >>> >>> * A yaml/json/xml/foo-encoded file that describes metadata necessary >>> to determine a value. This could even include code inline, I >>> assume. >>> >>> I like the last one best, and really, you could autodetect: If >>> it's a >>> plain file name (no extension) and isn't executable, it's a value; >>> if >>> it's executable, it's a script; if it has a supported extension, >>> parse >>> it and interpret it internally. >> >> You can have that in an even simpler manner. Just make every fact a >> runnable script that yields YAML or plaintext and returns 0 on >> success. >> >>> >>>> >>>> 5. Keep Facter simple. >>>> >>>> My love of facter stems from how easy it is to create new facts, >>>> and >>>> to interpret the data that comes from it. Please don't break that! >>> >> >> If I put all my ideas together I imagine something like the >> following: >> >> - facter itself becomes a hub for scripts that yield YAML >> - we need a factshell that can run the existing facts >> >> The collection of facts would work like the following: >> >> foreach dir in factpath: >> foreach file in dir: >> if file is executable and no fact called "file" exists: >> execute file >> if returncode is 0: >> new fact called "file" with value from scripts output >> >> The whole thing feels simple, but you could do almost everything with >> it :) >> The conventions for the fact scripts could be really simple: If it >> doesn't output anything or returns nonzero it failed. Otherwise its >> output is treated as YAML. (is a single line of text valid yaml? If >> not >> then we'd need a special case here). >> >> Instead of considering namespaces we could just have a single YAML >> that >> contains hashes of factname and factvalue. >> To support something like namespaces one could support subdirectories >> in the factpath. If you had a script in /etc/fact.d/foo/bar that >> yields >> the following: >> --- >> This is the value of foo/bar >> --- >> >> The resulting excerpt from facters YAML would look like that: >> --- >> foo: >> bar: This is the value of the foo/bar >> --- >> >> Of course, you could have achieved the same result with a script in >> /etc/fact.d/foo that yields the following: >> --- >> bar: This is the value of foo/bar >> --- >> >> Having said that: it would be probably quite easy to implement that >> "new" >> facter, because the interface is simple and facter itself >> doesn't have to do too much. The whole logig goes into the scripts. >> Of >> course facter should provide some kind of "factshell" (something >> you can >> put after your #!) that makes writing facts simple. However, nobody >> has >> to use that factshell and every script becomes a first-class citizen. >> >> -- >> Solvention >> Egermannstr. 6-8 >> 53359 Rheinbach >> >> Tel: +49 2226 158179-0 >> Fax: +49 2226 158179-9 >> >> http://www.solvention.de >> mailto:i...@solvention.de >> > > > -- > Nigel Kersten > Systems Administrator > Tech Lead - MacOps > > > -- :: 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 -~----------~----~----~----~------~----~------~--~---
