Puppet users - Mar 2010 - Apps that are using facter as a library or shell out to facter?

As we''re pondering future enhancements to facter, it seems useful to
better understand things (other than Puppet) that are using facter.

Do you have a script/application that shells out to facter or uses it
from as a Ruby library to collect information?   (I''m aware of
mcollective supporting facter, but that''s about it).

If so, can you tell us a little more about it?    What does it do?

Also, are their other datasources you would like to see in the core
''facts'' out of the box (without having to write your own),
that aren''t
there presently?

--Michael

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

''lo,

----- "Michael DeHaan" <michael@reductivelabs.com> wrote:
> Do you have a script/application that shells out to facter or uses it
> from as a Ruby library to collect information?   (I''m aware of
> mcollective supporting facter, but that''s about it).
my biggest hassle with it is that it''s quite slow.  Though I guess
that''s to be expected given what it does.

It would be good if facts can mark themselves volatile or not, and that
Facter.reset (or a similar call) could only affect the facts that have marked
themselves as subject to frequent changes.

Looking through my factlist things like architecture hardwareisa, hardwaremodel
- most things that came from dmidecode - kernel version, lsb* and a fair few
more should be fixed and not reset as often.  Though it''s true that in
newer virtualized environments things like ram size, cpu count etc can change on
the fly.

This will mean things like mcollective that is quite time critical can suffer a
bit less at the hands of facter.

-- 
R.I.Pienaar

-- 
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 15 March 2010 17:26, R.I.Pienaar <rip@devco.net>
wrote:
> ''lo,
>
> ----- "Michael DeHaan" <michael@reductivelabs.com> wrote:
>
>> Do you have a script/application that shells out to facter or uses it
>> from as a Ruby library to collect information?   (I''m aware of
>> mcollective supporting facter, but that''s about it).
>
> my biggest hassle with it is that it''s quite slow.  Though I guess
that''s to be expected given what it does.
>
> It would be good if facts can mark themselves volatile or not, and that
Facter.reset (or a similar call) could only affect the facts that have marked
themselves as subject to frequent changes.
Yeah, not sure how this would look in the current api though, I guess
something comparable to confine to allow timeouts and also
ttl/expiry/cache-control type things on the fact. Again this probably
comes after having configuration (so as to set a state dir, default
policy, etc).
> Looking through my factlist things like architecture hardwareisa,
hardwaremodel - most things that came from dmidecode - kernel version, lsb* and
a fair few more should be fixed and not reset as often.  Though it''s
true that in newer virtualized environments things like ram size, cpu count etc
can change on the fly.
Yeah that''s certainly one of the things I want to do, as is if
we''re
calling out to a command to parse it and can cache/process it in one
time as opposed to calling a billion ifconfig/dmidecodes that''d be
good too.

Paul

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

> Yeah that''s certainly one of the things I want to do, as is if
we''re
> calling out to a command to parse it and can cache/process it in one
> time as opposed to calling a billion ifconfig/dmidecodes that''d be
> good too.
Yep, if you''re shelling out or executing ''puppet''
without the daemon,
in memory caching doesn''t work.  (But how slow are we really?)

Cache dir would be simple though...

You could simply stat the file and see when the last fact storage run
happened, and each module could set (or not set) a timeout on a
case-by-case basis.
No timeout would mean don''t cache, so it would automatically work with
any existing facts, and the facts wouldn''t have to implement the
caching
themselves.

Things like OS version are inexpensive but wouldn''t have to be checked
too frequently, I''d bet :)

--Michael

-- 
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 3/15/2010 6:49 PM, Michael DeHaan wrote:
>> Yeah that''s certainly one of the things I want to do, as is if
we''re
>> calling out to a command to parse it and can cache/process it in one
>> time as opposed to calling a billion ifconfig/dmidecodes
that''d be
>> good too.
>
> Yep, if you''re shelling out or executing
''puppet'' without the daemon,
> in memory caching doesn''t work.  (But how slow are we really?)
munin has the same problem on the agents: shelling out with a simple 
text pipe interface gives HUGE(!!) flexibility but hurts collection 
performance.


 > Cache dir would be simple though...
 >
 > You could simply stat the file and see when the last fact storage run
 > happened, and each module could set (or not set) a timeout on a
 > case-by-case basis.
 > No timeout would mean don''t cache, so it would automatically work
with
 > any existing facts, and the facts wouldn''t have to implement the
 > caching
 > themselves.

Exactly, just add a "ttl-hint: 24" (hours) value to the JSON.

On the other hand, stuff like --test should probably ignore such hints.



Best Regards, David


-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

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

>
> Exactly, just add a "ttl-hint: 24" (hours) value to the JSON.
Hmm....

I''d saw this as something that would be a property of the fact, rather
than the output of the fact.

That is, I didn''t see a need for variable timeouts.

That being said, if we do the "fact.d" for plugins, those scripts will
want to also use this mechanism,
so perhaps those /do/ speak it in JSON.
>
> On the other hand, stuff like --test should probably ignore such hints.
Yep.

-- 
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 3/16/2010 10:15 PM, Michael DeHaan wrote:
>>
>> Exactly, just add a "ttl-hint: 24" (hours) value to the JSON.
>
> Hmm....
>
> I''d saw this as something that would be a property of the fact,
rather
> than the output of the fact.
>
> That is, I didn''t see a need for variable timeouts.
>
> That being said, if we do the "fact.d" for plugins, those scripts
will
> want to also use this mechanism,
> so perhaps those /do/ speak it in JSON.
If the only interface between a fact and facter is the JSON pipe, the 
TTL would have to be part of it. If it is a ruby interface, it''d 
probably be some kind of accessor which too could have a code block 
attached to make fancy calculations.

As alwas in IT (and elsewhere): just becaus you can (make variable 
timeouts) it doesn''t mean it''s a good idea.



Best regards, David
-- 
dasz.at OG              Tel: +43 (0)664 2602670     Web: http://dasz.at
Klosterneuburg                                         UID: ATU64260999

        FB-Nr.: FN 309285 g          FB-Gericht: LG Korneuburg

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