Puppet users - Jan 2009 - Facter - the future - your input needed

-----BEGIN PGP SIGNED MESSAGE-----
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-----


--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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 - root@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,
> 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.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
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-----

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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!




--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> -----Original Message-----
> From: puppet-users@googlegroups.com [mailto:puppet-
> users@googlegroups.com] On Behalf Of James Turnbull
> Sent: 29 January 2009 21:55
> To: puppet-users@googlegroups.com; puppet-dev@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.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Jan 30, 2009 at 6:58 AM, Ross McKerchar
<Ross.McKerchar@sophos.com> wrote:
>
>
>
>> -----Original Message-----
>> From: puppet-users@googlegroups.com [mailto:puppet-
>> users@googlegroups.com] On Behalf Of James Turnbull
>> Sent: 29 January 2009 21:55
>> To: puppet-users@googlegroups.com; puppet-dev@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.
>
I was planning on suggesting this same feature. We have a few facts
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

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

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

On 1/29/09 10:55 PM, "James Turnbull" <james@lovedthanlost.net>
wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 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-----
> 
> 
> > 

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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

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.

I also think JSON would be very nice to have, although at present I  
don''t have any code that would immediately use it.

Don




--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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?

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.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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."

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

+1 for cached objects.


On Sun, Feb 1, 2009 at 3:18 PM, Sam Rowe <sam@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."
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I don''t think that belongs in facter; it belongs in the fact itself.

Just my .02

--Paul

On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe <sam@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."
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

In general I agree, and thats how I''ve implemented it so far (e.g. with
a
yaml dump) but when 50% of your facts require caching, it might be better to
let facter handle it centrally in one global caching file.

cheers,
Ohad

On Mon, Feb 2, 2009 at 2:41 AM, Paul Lathrop <paul@tertiusfamily.net>
wrote:
>
> I don''t think that belongs in facter; it belongs in the fact
itself.
>
> Just my .02
>
> --Paul
>
> On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe <sam@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."
> >
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Sun, Feb 1, 2009 at 10:41 AM, Paul Lathrop <paul@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?

>
> Just my .02
>
> --Paul
>
> On Sat, Jan 31, 2009 at 11:18 PM, Sam Rowe <sam@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."
>>
>> >
>>
>
> >
>


-- 
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 30, 2009, at 6:10 AM, Mike Pountney wrote:
>
>
> 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 | 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 31, 2009, at 9:31 AM, Don Jackson wrote:
>
>
>> 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 | 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 1, 2009, at 1:07 AM, Sam Rowe wrote:
> 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 | 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 1, 2009, at 1:18 AM, Sam Rowe 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."

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 | 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 1, 2009, at 10:42 PM, Nigel Kersten wrote:
> On Sun, Feb 1, 2009 at 10:41 AM, Paul Lathrop  
> <paul@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
---------------------------------------------------------------------
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Wed, Feb 4, 2009 at 10:08 PM, Luke Kanies <luke@madstop.com> wrote:
> 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.


-- 
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Jan 30, 2009 at 7:58 AM, Ross McKerchar
<Ross.McKerchar@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

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Feb 13, 2009 at 4:49 PM, Jeff Falgout <jtfalgout@gmail.com>
wrote:
> On Fri, Jan 30, 2009 at 7:58 AM, Ross McKerchar
> <Ross.McKerchar@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

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jan 29, 4:55 pm, James Turnbull <ja...@lovedthanlost.net>
wrote:
>
> 2.  Additional output formats - JSON, XML? (winces) - Facter already
> outputs in YAML.
What about LDIF? Since Puppet can pull info from LDAP, it would be
nice if facter made it easy to add/update entries in your directory.
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Feb 17, 2009, at 12:09 PM, Rob McBroom wrote:
>
> On Jan 29, 4:55 pm, James Turnbull <ja...@lovedthanlost.net> wrote:
>>
>> 2.  Additional output formats - JSON, XML? (winces) - Facter already
>> outputs in YAML.
>
> What about LDIF? Since Puppet can pull info from LDAP, it would be
> nice if facter made it easy to add/update entries in your directory.
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
---------------------------------------------------------------------
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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:info@solvention.de

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.rogge@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:info@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

+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.rogge@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:info@solvention.de
>>
>
>
> -- 
> Nigel Kersten
> Systems Administrator
> Tech Lead - MacOps
>
> >
-- 
:: udo waechter - root@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I''d vote for the push to Marshal over YAML since Marshal appears to be
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

On Wed, Feb 18, 2009 at 19:13, Nigel Kersten <nigelk@google.com>
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.rogge@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:info@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

My 2c on the matter is that JSON is the fastest, most portable, and  
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.


--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---






Regards,

AJ

On 22/02/2009, at 3:22 PM, Trevor Vaughan wrote:
>
> I''d vote for the push to Marshal over YAML since Marshal appears
to be
> 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
>
> On Wed, Feb 18, 2009 at 19:13, Nigel Kersten <nigelk@google.com>  
> 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.rogge@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:info@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+unsubscribe@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>

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.

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---