Puppet users - Apr 2008 - Expanding Facter's manufacturer.rb

I''ve just filed http://reductivelabs.com/trac/puppet/ticket/1182 with
the aim of making it easier to add fact pickup from dmidecode in
manufacturer.rb.

As the ticket says, I think that the fact sections, keys and values
shouldn''t be hardcoded in manufacturer.rb, but should be stored in a
configuration file somewhere.  This means that a given stable
installation of Puppet can be expanded with additional manufacturer
facts without having to edit the .rb file, meaning your custom fact
requirements never get overwritten by an upgrade of Facter.

Thoughts on whether this is a good track to take?  Should the external
file be .rb syntax, or .ini or yaml (or .foobar) ?

I''ve also just realised I filed it under puppet, not facter.  Sorry
Luke.

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

Ah, I was just planning to do similar things as well :)

Well.. maybe it makes sense to share what I''m planning to add..

detection of dmidecode which is older than 2.9 - different output format
use --string options of dmidecode 2.9 - much easier to parse and avoid the
multiple executions of dmidecode (or execute it only per "string
query")

Hopefully I''ll get around to it in the next coulpe days.
Ohad

On Wed, Apr 9, 2008 at 6:40 PM, Duncan Hill <bajandude@googlemail.com>
wrote:
>
> I''ve just filed http://reductivelabs.com/trac/puppet/ticket/1182
with
> the aim of making it easier to add fact pickup from dmidecode in
> manufacturer.rb.
>
> As the ticket says, I think that the fact sections, keys and values
> shouldn''t be hardcoded in manufacturer.rb, but should be stored in
a
> configuration file somewhere.  This means that a given stable
> installation of Puppet can be expanded with additional manufacturer
> facts without having to edit the .rb file, meaning your custom fact
> requirements never get overwritten by an upgrade of Facter.
>
> Thoughts on whether this is a good track to take?  Should the external
> file be .rb syntax, or .ini or yaml (or .foobar) ?
>
> I''ve also just realised I filed it under puppet, not facter. 
Sorry Luke.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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 Wednesday, April 09, 2008 11:40:53 AM +0100 Duncan Hill 
<bajandude@googlemail.com> wrote:
> I''ve just filed http://reductivelabs.com/trac/puppet/ticket/1182
with
> the aim of making it easier to add fact pickup from dmidecode in
> manufacturer.rb.
>
> As the ticket says, I think that the fact sections, keys and values
> shouldn''t be hardcoded in manufacturer.rb, but should be stored in
a
> configuration file somewhere.  This means that a given stable
> installation of Puppet can be expanded with additional manufacturer
> facts without having to edit the .rb file, meaning your custom fact
> requirements never get overwritten by an upgrade of Facter.
>
> Thoughts on whether this is a good track to take?  Should the external
> file be .rb syntax, or .ini or yaml (or .foobar) ?
>
> I''ve also just realised I filed it under puppet, not facter. 
Sorry Luke.
I would prefer that the default be to report all the facts and have the 
config be used to suppress facts.  This way, you get all the facts you want 
without having to maintain yet-another-config-file unless you absolutely 
don''t want to care.

The downside is, this really depends on how many facts you really want to 
be pulling.  If facter is going to start throwing out lists of facts about 
everything and its mother like SNMP than definitely want to suppress 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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Digant C Kasundra wrote:
> --On Wednesday, April 09, 2008 11:40:53 AM +0100 Duncan Hill 
> <bajandude@googlemail.com> wrote:
> 
>> I''ve just filed
http://reductivelabs.com/trac/puppet/ticket/1182 with
>> the aim of making it easier to add fact pickup from dmidecode in
>> manufacturer.rb.
>>
>> As the ticket says, I think that the fact sections, keys and values
>> shouldn''t be hardcoded in manufacturer.rb, but should be
stored in a
>> configuration file somewhere.  This means that a given stable
>> installation of Puppet can be expanded with additional manufacturer
>> facts without having to edit the .rb file, meaning your custom fact
>> requirements never get overwritten by an upgrade of Facter.
>>
>> Thoughts on whether this is a good track to take?  Should the external
>> file be .rb syntax, or .ini or yaml (or .foobar) ?
>>
>> I''ve also just realised I filed it under puppet, not facter. 
Sorry Luke.
> 
> I would prefer that the default be to report all the facts and have the 
> config be used to suppress facts.  This way, you get all the facts you want
> without having to maintain yet-another-config-file unless you absolutely 
> don''t want to care.
I haven''t had a chance to respond to this thread but as Facter de-facto
maintainer - +1.  I''d be very reluctant to support external
configuration files.

Regards

James Turnbull

- --
James Turnbull (james@lovedthanlost.net)
- --
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

iD8DBQFH/qJa9hTGvAxC30ARAr+8AJ9QJiOOdqyaEaE1O+KPHgRLihbNmwCgtAsm
WkOR9cXwgZMiLB3RumDPuDk=kqtx
-----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 11/04/2008, James Turnbull <james@lovedthanlost.net>
wrote:
>  Digant C Kasundra wrote:
>  > I would prefer that the default be to report all the facts and have
the
>  > config be used to suppress facts.  This way, you get all the facts
you want
>  > without having to maintain yet-another-config-file unless you
absolutely
>  > don''t want to care.
>
> I haven''t had a chance to respond to this thread but as Facter
de-facto
>  maintainer - +1.  I''d be very reluctant to support external
>  configuration files.
My only concern with having the list hard-coded in manufacturer.rb (as
it is right now) is that any local modifications made to what to
include or throw away will be overwritten every time Puppet is
upgraded.  This, to me, is not a good thing, as something that was
working suddenly won''t be.  You can''t put the local modified
version
into Puppet for management, because the upgrade will overwrite it, and
then Puppet overwrites the upgrade - potentially losing new
functionality.

dmidecode generates a lot of information, most of which is probably
useless to Puppet - type of DIMM in slot 1 is a nice inventory thing,
but not a management thing per se (and the current dmidecode parser
won''t handle it either, multiple sections can have the same title).

My two aims were to find a way to tell Facter ''Hey, I want to know
this fact as well'', and not be confined to solely ''System
Information''.  The patch (which I need to resubmit to the right trac)
did the second part more than the first, though I added a hard-code
for the former.

Would ''If /etc/facter/dmidecode.foo exists, read it for additional
section+key+value configs'' be acceptable?  This leaves the current
status quo of no external config files by default, but also allows the
administrator to supplement the hard-code without having to hack
Facter itself.

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

Duncan Hill wrote:
> My only concern with having the list hard-coded in manufacturer.rb (as
> it is right now) is that any local modifications made to what to
> include or throw away will be overwritten every time Puppet is
> upgraded.  This, to me, is not a good thing, as something that was
> working suddenly won''t be.  You can''t put the local
modified version
> into Puppet for management, because the upgrade will overwrite it, and
> then Puppet overwrites the upgrade - potentially losing new
> functionality.
I have no issues with your initial patch - happy to apply it.

But excuse me if I am missing your point but you should probably check
out custom facts - the model there allows your own facts to be managed
and maintained and not impacted by upgrades or changes to Puppet.

http://reductivelabs.com/trac/puppet/wiki/AddingFacts

Additionally, Facter separates out facts into smaller .rb files (in the
next release most, if not all, facts will be split out of facter.rb).
All facts will live in the lib/facter directory and Facter will load all
files it finds in there (as it does now).  That means you can drop in
facts and when you upgrade those facts will not be touched.

It''s not how I''d recommend doing it - I''d recommend
using custom facts -
but this will allow you to make use of/expand the
facter/util/manufacturer.rb Class that returns the dmicode data.
> Would ''If /etc/facter/dmidecode.foo exists, read it for additional
> section+key+value configs'' be acceptable?  This leaves the current
> status quo of no external config files by default, but also allows the
> administrator to supplement the hard-code without having to hack
> Facter itself.
I really don''t like this idea - I''d prefer to just add the
required
additional facts or have people add their own facts rather than add
another configuration file to be managed.

Regards

James Turnbull

- --
James Turnbull (james@lovedthanlost.net)
- --
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

iD8DBQFH/zxN9hTGvAxC30ARArBvAJ9CQFNghDsvvSJ793nF0c+fD94PvwCePLzo
z/95KZj50u/eIc3LWaW/86A=iWZ3
-----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 Thu, Apr 10, 2008 at 4:27 PM, James Turnbull <james@lovedthanlost.net>
wrote:
>  I haven''t had a chance to respond to this thread but as Facter
de-facto
>  maintainer - +1.  I''d be very reluctant to support external
>  configuration files.
This seems to go against the whole ethos of facter.

If people want to write their own facts that do this, that''s another
matter, but I think a great strength of facter is that it doesn''t have
much in the way of external requirements.


-- 
Nigel Kersten
Systems Administrator
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
-~----------~----~----~----~------~----~------~--~---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nigel Kersten wrote:
> On Thu, Apr 10, 2008 at 4:27 PM, James Turnbull
<james@lovedthanlost.net> wrote:
>>  I haven''t had a chance to respond to this thread but as
Facter de-facto
>>  maintainer - +1.  I''d be very reluctant to support external
>>  configuration files.
> 
> This seems to go against the whole ethos of facter.
> 
> If people want to write their own facts that do this, that''s
another
> matter, but I think a great strength of facter is that it doesn''t
have
> much in the way of external requirements.
My point exactly - Facter is relatively (excluding the obvious
requirement for Ruby) portable right now.  Why complicate that?

Regards

James Turnbull

- --
James Turnbull (james@lovedthanlost.net)
- --
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 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH/2nB9hTGvAxC30ARArgWAJ9kEGJBawXxrknNrLdhyfaT8mDqlACg1/X8
j4wHjwdLVErLFKMvtPm1wPM=sDWE
-----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 11/04/2008, James Turnbull <james@lovedthanlost.net>
wrote:
>  But excuse me if I am missing your point but you should probably check
>  out custom facts - the model there allows your own facts to be managed
>  and maintained and not impacted by upgrades or changes to Puppet.
>
>  http://reductivelabs.com/trac/puppet/wiki/AddingFacts
Ahhh - that page didn''t turn up in my searches of the wiki, even when
I turned tickets and changesets off.  Much nicer implementation, and
it while I''d have to call dmidecode again, I can live with that level
of overhead.

Thanks for the clue x 4, I''ll go fiddle with custom facts now :)

--~--~---------~--~----~------------~-------~--~----~
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 figured I''d just throw this out here since others working on these  
things might find it useful.

I wrote this module to start abstracting different sources of  
inventory information, this first class is for lshw, but it looks like  
I''m not going to be able to keep working on it.  The plan was to add  
dmidecode support and start breaking each feature out into modular  
chunks in much the way that puppet does with providers.  My idea was  
to make this into some sort of provider framework for facter.

Get it here: http://blakebarnett.com/code/inventory.rb

Usage is something like:
 >> require ''inventory''
=> true
 >> lshw = Inventory::Lshw.new
 >> lshw.memory
=> {:node=>"", :description=>"System Memory",
:slot=>"System board or
motherboard", :physid=>"b", :size=>"268435456"}

There are probably much more efficient ways of doing this.  :) Anyway,  
I hope someone finds it useful.

-Blake


On Apr 9, 2008, at 8:07 PM, Ohad Levy wrote:
> Ah, I was just planning to do similar things as well :)
>
> Well.. maybe it makes sense to share what I''m planning to add..
>
> detection of dmidecode which is older than 2.9 - different output  
> format
> use --string options of dmidecode 2.9 - much easier to parse and  
> avoid the multiple executions of dmidecode (or execute it only per  
> "string query")
>
> Hopefully I''ll get around to it in the next coulpe days.
> Ohad
>
> On Wed, Apr 9, 2008 at 6:40 PM, Duncan Hill  
> <bajandude@googlemail.com> wrote:
>
> I''ve just filed http://reductivelabs.com/trac/puppet/ticket/1182
with
> the aim of making it easier to add fact pickup from dmidecode in
> manufacturer.rb.
>
> As the ticket says, I think that the fact sections, keys and values
> shouldn''t be hardcoded in manufacturer.rb, but should be stored in
a
> configuration file somewhere.  This means that a given stable
> installation of Puppet can be expanded with additional manufacturer
> facts without having to edit the .rb file, meaning your custom fact
> requirements never get overwritten by an upgrade of Facter.
>
> Thoughts on whether this is a good track to take?  Should the external
> file be .rb syntax, or .ini or yaml (or .foobar) ?
>
> I''ve also just realised I filed it under puppet, not facter. 
Sorry
> Luke.
>
>
>
>
> >

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