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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
