Facter - the future - your input needed
James Turnbull
Hash: SHA1
Hi all
We're currently looking at the next release of Facter and the future
direction of the tool. I'd like to try and prompt some discussions on
facter and what people want from it.
As a starter here's some (although not all) of the ideas we'll be
working through:
1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
network -> interface -> ipaddress.
2. Additional output formats - JSON, XML? (winces) - Facter already
outputs in YAML.
3. Additional collection mechanisms, for example the ability to
specify a fact file, /etc/facter.conf, containing fact name=value pairs.
4. A more Ruby DSL for facts
5. Rich data structures/values in facts
If you have additional ideas/requirements/issues/comments we'd welcome
feedback.
Regards
James Turnbull
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJgiXA9hTGvAxC30ARArNJAKCj418VAL75gadKW52gJXSi8JUOywCguDFe
QPHAtJgrArGhBch4t+7QhrU=
=sNRM
-----END PGP SIGNATURE-----
udo waechter
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 - ro...@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
Julian Simpson
> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
> network -> interface -> ipaddress.
Sounds interesting.
> 2. Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
YAML support is growing. .NET developers are starting to use YAML.
I'd never choose XML output over other features. Maybe if an
"enterprise" client wanted to pay Luke to implement it :)
> 3. Additional collection mechanisms, for example the ability to
> specify a fact file, /etc/facter.conf, containing fact name=value pairs.
/etc/factor.d ?
> 4. A more Ruby DSL for facts
I'd like to see that. I can't justify it in terms of any additional
benefit that it would give right now, but it seems useful.
J.
James Turnbull
Hash: SHA1
Julian Simpson wrote:
>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> YAML support is growing. .NET developers are starting to use YAML.
> I'd never choose XML output over other features. Maybe if an
> "enterprise" client wanted to pay Luke to implement it :)
Any formats would be supplemental rather than reductive. XML was an
off-the-wall idea. I think Marshal and JSON make more sense. But other
ideas welcomed.
>> 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.
>> 4. A more Ruby DSL for facts
>
> I'd like to see that. I can't justify it in terms of any additional
> benefit that it would give right now, but it seems useful.
Thanks for your feedback!
Cheers
James
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJgtVL9hTGvAxC30ARAgQuAJ4r2AI8asIbP+HbD80u0fgoz3HyVgCgh2TJ
R+SOp0TwCATHXFXt+RH5ZWw=
=gFqL
-----END PGP SIGNATURE-----
Mike Pountney
On 30 Jan 2009, at 10:24, James Turnbull wrote:
> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
> network -> interface -> ipaddress.
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?
If this effectively adds [something akin to] hash support to the
puppet language then it's a brilliant idea.
>
> Julian Simpson wrote:
>>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>>> outputs in YAML.
>>
>> YAML support is growing. .NET developers are starting to use YAML.
>> I'd never choose XML output over other features. Maybe if an
>> "enterprise" client wanted to pay Luke to implement it :)
>
> Any formats would be supplemental rather than reductive. XML was an
> off-the-wall idea. I think Marshal and JSON make more sense. But
> other
> ideas welcomed.
XML would be useful at our end. Having a mechanism to easily write new
output formats (with a plugin architecture?) would be good.
>
>
>>> 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.
With a simple /etc/factor.d/fact-name file containing a fact value?
---
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!
Ross McKerchar
> -----Original Message-----
> From: puppet...@googlegroups.com [mailto:puppet-
> us...@googlegroups.com] On Behalf Of James Turnbull
> Sent: 29 January 2009 21:55
> To: puppet...@googlegroups.com; puppe...@googlegroups.com
> Subject: [Puppet Users] Facter - the future - your input needed
>
> Hi all
>
> We're currently looking at the next release of Facter and the future
> direction of the tool. I'd like to try and prompt some discussions on
> facter and what people want from it.
My 2 cents:
As I'm not great at ruby, I find writing facts and distributing them to do a really simple thing can be a bit painful. Along these lines what about:
1) The option to point facter at a directory and then all the scripts in the directory are simply facts (say, factname is scriptname and value is output of script). A bit messy but very simple.
2) If using namespaces can we expose the boxes local snmp tree via facter? There's a lot of useful info in there. Obviously wouldn't want all that printed out everytime you type "facter" of course :)
But I also agree it should be kept very simple - it's definitely a good Unix example of one tool, one job done well and should remain so. Puppet is a better placed to handle the complexity - for that reason I'm not convinced facter should ever try access the network for facts: is keeping your puppet node information in ldap with extra variables not a better way to do that?
-ross
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
Nigel Kersten
<Ross.Mc...@sophos.com> wrote:
>
>
>
>> -----Original Message-----
>> From: puppet...@googlegroups.com [mailto:puppet-
>> us...@googlegroups.com] On Behalf Of James Turnbull
>> Sent: 29 January 2009 21:55
>> To: puppet...@googlegroups.com; puppe...@googlegroups.com
>> Subject: [Puppet Users] Facter - the future - your input needed
>>
>> Hi all
>>
>> We're currently looking at the next release of Facter and the future
>> direction of the tool. I'd like to try and prompt some discussions on
>> facter and what people want from it.
>
> My 2 cents:
>
> As I'm not great at ruby, I find writing facts and distributing them to do a really simple thing can be a bit painful. Along these lines what about:
>
> 1) The option to point facter at a directory and then all the scripts in the directory are simply facts (say, factname is scriptname and value is output of script). A bit messy but very simple.
>
that are simply wrappers around external scripts in other languages,
primarily because of pre-existing libraries that we don't have
equivalents for in Ruby.
I'm not quite sure how this would work with factsync with Puppet
though. Maybe check if a script can be parsed as Ruby, if not, try to
execute it?
> 2) If using namespaces can we expose the boxes local snmp tree via facter? There's a lot of useful info in there. Obviously wouldn't want all that printed out everytime you type "facter" of course :)
>
> But I also agree it should be kept very simple - it's definitely a good Unix example of one tool, one job done well and should remain so. Puppet is a better placed to handle the complexity - for that reason I'm not convinced facter should ever try access the network for facts: is keeping your puppet node information in ldap with extra variables not a better way to do that?
>
> -ross
>
> Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
> Company Reg No 2096520. VAT Reg No GB 348 3873 20.
>
> >
>
Nigel Kersten
Systems Administrator
Tech Lead - MacOps
Jos Houtman
I have only developed an ip/interface fact that uses ip2 instead of
ifconfig. In order to detect multiple ip's per interface.
And my conclusion was that I really wanted some complexer data structures
and an easier integration with puppet.
jos
Don Jackson
2. Additional output formats - JSON, XML? (winces) - Facter already
outputs in YAML.
Sam Rowe
but just in case:
We recently upgraded a couple of machines from facter 1.3.x to facter
1.5.x and were very dismayed to learn that $operatingsystemrelease on
Solaris had changed from the consistent-with-other-operatingsystems
"5.9" to "9_u8". This made us wonder if we'd need a different version
for every Solaris update (assuming "u8" is update 8, I really have no
idea what it means.) On RHEL and HP-UX $operatingsystemrelease didn't
change and is what we'd expect (as "5.9" was what we'd expect.)
I haven't taken the time to find the checkin that changed it and read
the justification, perhaps it's the best thing ever, but it threw us
for a loop and broke a lot of branches. Are there Solaris people who
are really in need of that level of detail? You really treat u7
differently than u8?
Perhaps our approach is also the problem... we run RHEL4 and 5, HP-UX
11.11 and soon 11.31 and Solaris 9 and 10. Across these OSes,
$operatingsystemrelease made sense to us (as the numbers in the
previous sentence) moreso than say $kernelversion because on RHEL we
don't necessarily have the same kernel running everywhere (or want to
depend on that) but we do have things we want to do on RHEL4 vs 5 so
branching on $kernelversion doesn't really work in the way we'd been
branching on $operatingsystemrelease.
I too love the idea of a facter.d that can run scripts/bins in
whatever language. I hope that the location of that directory won't be
hard-wired. The difficult part of this then becomes the namespacing of
these facts and/or returning multiple facts from the same script.
Sam Rowe
way to say that a given fact (or set of facts) is cache-able. Perhaps
your fact is resource intensive to discover and doesn't change much.
It'd be cool to have a built-in facility in facter that says "if you
just booted, find out this fact, otherwise use the old answer."
Ohad Levy
Paul Lathrop
Just my .02
--Paul
Ohad Levy
cheers,
Ohad
Nigel Kersten
>
> I don't think that belongs in facter; it belongs in the fact itself.
Why not have a simple declaration in your fact that gives you the
behavior you want?
>
> Just my .02
>
> --Paul
>
> On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe <s...@samrowe.com> wrote:
>>
>> Oh and one other thing about 'facter.d' it'd be cool if there was some
>> way to say that a given fact (or set of facts) is cache-able. Perhaps
>> your fact is resource intensive to discover and doesn't change much.
>> It'd be cool to have a built-in facility in facter that says "if you
>> just booted, find out this fact, otherwise use the old answer."
>>
>> >
>>
>
> >
>
Luke Kanies
>
> 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
Luke Kanies
>
>
> On 30 Jan 2009, at 10:24, James Turnbull wrote:
>> 1. Namespaces - add a namespace or tiered namespace to Facter, i.e.
>> network -> interface -> ipaddress.
>
> 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?
>
> 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.
>> Julian Simpson wrote:
>>>> 2. Additional output formats - JSON, XML? (winces) - Facter
>>>> already
>>>> outputs in YAML.
>>>
>>> YAML support is growing. .NET developers are starting to use YAML.
>>> I'd never choose XML output over other features. Maybe if an
>>> "enterprise" client wanted to pay Luke to implement it :)
>>
>> Any formats would be supplemental rather than reductive. XML was an
>> off-the-wall idea. I think Marshal and JSON make more sense. But
>> other
>> ideas welcomed.
>
> 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.
>>>> 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.
>
> 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.
>
> 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!
Definitely a goal.
--
Basic research is what I am doing when I don't know what I am doing.
--Wernher von Braun
Luke Kanies
>
>
>> 2. Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> I'd vote for adding an optional output format to easily support
> shell scripts:
>
> Here is the shell compatible output of another tool I use:
>
> set -A os_version_major "4"
> set -A os_version_minor "4"
> set -A packages "subversion-1.4.4p0" "screen-4.0.3p1" "rsync-3.0.3"
> "nut-2.2.1p0" "wget-1.11.3" "ncftp-3.2.1" "bash-3.2.39" "amanda-
> client-2.4.5.1"
>
> It is very useful to be able to call out from a shell script, get
> this kind of result back, and all the data returned is now available
> via environment variables.
This is totally awesome. I would have never thought of shell output
for Facter, but I can definitely see how you'd want this.
> Given that Facter already supports a way of feeding environment
> variables INTO facter, eg:
>
> Also, Facter will search through your environment for any variables
> whose names start with ‘FACTER_’ (case insensitive)
> and automatically add those facts.
>
> Perhaps the right thing to do is prepend FACTER_ to all the fact
> names for the shell output format.
It should definitely be straightforward to do.
--
Always be wary of any helpful item that weighs less than its operating
manual. -- Terry Pratchett
Luke Kanies
> I'm guessing this isn't the variety of feedback you're looking for,
> but just in case:
>
> We recently upgraded a couple of machines from facter 1.3.x to facter
> 1.5.x and were very dismayed to learn that $operatingsystemrelease on
> Solaris had changed from the consistent-with-other-operatingsystems
> "5.9" to "9_u8". This made us wonder if we'd need a different version
> for every Solaris update (assuming "u8" is update 8, I really have no
> idea what it means.) On RHEL and HP-UX $operatingsystemrelease didn't
> change and is what we'd expect (as "5.9" was what we'd expect.)
>
> I haven't taken the time to find the checkin that changed it and read
> the justification, perhaps it's the best thing ever, but it threw us
> for a loop and broke a lot of branches. Are there Solaris people who
> are really in need of that level of detail? You really treat u7
> differently than u8?
Hmm. That seems like a bug, and was probably caused in the switch to
using uname -v instead of parsing /etc/release (which doesn't exist
everywhere).
We certainly didn't mean to change the results here.
In other words, we try to maintain backward compatibility, and we'll
definitely try to here, including publishing release candidates for
every release.
--
Don't tell me how hard you work. Tell me how much you get done.
-- James Ling
Luke Kanies
This is a good idea. It should be straightforward to add support for
a ttl to facts.
--
The people who are regarded as moral luminaries are those who forego
ordinary pleasures themselves and find compensation in interfering
with the pleasures of others. -- Bertrand Russell
Luke Kanies
> On Sun, Feb 1, 2009 at 10:41 AM, Paul Lathrop
> <pa...@tertiusfamily.net> wrote:
>>
>> I don't think that belongs in facter; it belongs in the fact itself.
>
> Sure, but should everyone have to write the same code to do it?
>
> Why not have a simple declaration in your fact that gives you the
> behavior you want?
I agree; time-to-live is pretty fundamental, and should be
straightforward to add.
--
Fallacies do not cease to be fallacies because they become fashions.
--G. K. Chesterton
Nigel Kersten
> 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.
++
I'm totally in favor of having all three options there, and yes,
autodetection should be really easy.
I hadn't thought of having files that contain a simple value, but once
it was raised, I realized that we have a whole bunch of facts that
could be switched over to using this method.
Jeff Falgout
<Ross.Mc...@sophos.com> wrote:
> As I'm not great at ruby, I find writing facts and distributing them to do a really simple thing can be a bit painful. Along these lines what about:
>
As Luke put it for python - ruby makes my eyes bleed - I struggle
with Ruby a lot and often I give up what I'm trying to do with facts.
> 1) The option to point facter at a directory and then all the scripts in the directory are simply facts (say, factname is scriptname and value is output of script). A bit messy but very simple.
>
Messy - but ohhhh so useful. Even if facter only parses a text file -
removing the Ruby requirement goes a long way in my mind!
I love this idea - Andrew, Luke, et al this would be kick arse!! Purty
Puhleeeese, can we have that at the top of the list !!
Cheers -
Jeff
Jeff Falgout
> On Fri, Jan 30, 2009 at 7:58 AM, Ross McKerchar
> <Ross.Mc...@sophos.com> wrote:
>
>
>> As I'm not great at ruby, I find writing facts and distributing them to do a really simple thing can be a bit painful. Along these lines what about:
>>
>
> As Luke put it for python - ruby makes my eyes bleed - I struggle
> with Ruby a lot and often I give up what I'm trying to do with facts.
>
>> 1) The option to point facter at a directory and then all the scripts in the directory are simply facts (say, factname is scriptname and value is output of script). A bit messy but very simple.
>>
>
> Messy - but ohhhh so useful. Even if facter only parses a text file -
> removing the Ruby requirement goes a long way in my mind!
>
Thinking about this a bit more - I'd probably rely on Facts a whole
heck of a lot more - to the point of abusing them. I'm not sure this
is the best approach but it'd sure help me get the job done faster.
Jeff
The Anarcat
I'm not sure this is relevant, too late or simply already implemented,
but I'd like to have array of facts.
A very good example is the "ssh_keys" resource: i'd like to access
$ssh_keys['root'] and distributed that as an authorized_keys to other
nodes. I need this for my backups. :)
I'm sure it could have other uses (network interfaces come to mind).
Maybe this would be solved by namespaces though...
--
Antoine Beaupré
Réseau Koumbit Networks
+1.514.387.6262
Rob McBroom
>
> 2. Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
nice if facter made it easy to add/update entries in your directory.
Luke Kanies
When originally developed, in the dawn of time, the facter => ldap
connection was handled by 'enhost'. It had the schema and knew how to
actually talk to ldap, the idea being Facter was focused on facts and
nothing else, and enhost was focused on ldap.
AFAIK, no one has used enhost in years.
I'm not opposed to ldif as an output; well, really, output formats
should clearly be componentized, so it should be easy to add new ones.
--
Honest criticism is hard to take, particularly from a relative, a
friend, an acquaintance, or a stranger. -- Franklin P. Jones
Andreas Rogge
> 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
Nigel Kersten
for ibternal representations?
The benefit of yaml is that it is human readable. I don't think it
makes sense internally.
My 2c.
Udo Waechter
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.
:: udo waechter - ro...@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
Trevor Vaughan
nothing more than a serialized instance of a data structure.
There should definitely be a way to pass arrays though.
I'm currently getting around that by using a comma separated string
and running a 'split' on any facts that I use, but it feels a bit
hackish.
Trevor
AJ Christensen
supports all of the big boy data structures.
As for a tiered/namespaced setup; I wholeheartedly recommend this
change and I'm sure many facter/puppet users will appreciate it.
Don Jackson
On Feb 21, 2009, at 7:06 PM, AJ Christensen wrote:
> My 2c on the matter is that JSON is the fastest, most portable, and
> supports all of the big boy data structures.
I'd vote for JSON also.