Couple of questions related to facts: a) Are you (Luke/James) interested in adding additional facts to the main facter tree or do you prefer that additional facts are kept out of the main tree? Assuming you want them added to the main tree, then: b) Could we look at breaking the source into small pieces, so not all the fact logic is contained in the main facter.rb file? c) Do you have any preferences in terms of fact naming? What to shorten, what not to shorten and so on? d) Are the fact names supposed to be kept stable between versions? -- /peter
Slightly off topic here but...
...Ruby goes bonkers (tight loop, eats all your memory) if your pwd goes
away (e.g. file system gets unmounted) and your server basically dies.
Since this is upon %x{} it may be worth putting a safety check into
facter before shelling out, if we''re talking about refactoring facter.
Not ideal, but it would help.
I have ticketed the Ruby problem with Red Hat who should pass it
upstream if all goes to plan.
Derek
-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Peter Hoeg
Sent: 14 February 2008 12:02
To: Puppet User Discussion
Subject: [Puppet-users] Adding facts
Couple of questions related to facts:
a) Are you (Luke/James) interested in adding additional facts to the
main facter tree or do you prefer that additional facts are kept out of
the main tree?
Assuming you want them added to the main tree, then:
b) Could we look at breaking the source into small pieces, so not all
the fact logic is contained in the main facter.rb file?
c) Do you have any preferences in terms of fact naming? What to shorten,
what not to shorten and so on?
d) Are the fact names supposed to be kept stable between versions?
--
/peter
_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.
Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message. Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed. Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group. Replies to this email may be monitored
by the Barclays Group for operational or business reasons.
Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Hoeg wrote: | Couple of questions related to facts: | | a) Are you (Luke/James) interested in adding additional facts to the | main facter tree or do you prefer that additional facts are kept out | of the main tree? Outside of the main tree is my preference. | Assuming you want them added to the main tree, then: | | b) Could we look at breaking the source into small pieces, so not all | the fact logic is contained in the main facter.rb file? Breaking into smaller pieces is the planned direction. There is a refactor that I have committed (pending Luke''s comment) to do exactly this. The vast majority of facts will be split from facter.rb. | c) Do you have any preferences in terms of fact naming? What to | shorten, what not to shorten and so on? Happy to take discussion on this. Not overly fussed. | d) Are the fact names supposed to be kept stable between versions? | Yes - I think so to reduce potential for rewrite in people''s manifests. ~ Do you see something different here and if so why? (curious rather than antagonistic...) 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 iD8DBQFHtEqM9hTGvAxC30ARAgVAAJ9RG89H9UHN82HCpWBGhg4kukuZAQCgssAh 7m46x7wrhmfgOKhD90qpADY=A/cN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Turnbull wrote: | Peter Hoeg wrote: | | Couple of questions related to facts: | | | | a) Are you (Luke/James) interested in adding additional facts to the | | main facter tree or do you prefer that additional facts are kept out | | of the main tree? | | Outside of the main tree is my preference. | Ah - that could easily be misconstrued... I am looking for enhancements to existing facts that support new operating systems - AIX has been a recent example. Also new facts that provide baseline configuration information about any OS are also welcome. Obscure or unusual factoids are probably better as custom facts. 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 iD8DBQFHtEuE9hTGvAxC30ARApaOAJ0c3hftG44ZEnKqXg4sGg43mabtjACePdfM dQrf7oOcpOwAvFYtwbqvm9I=ShXJ -----END PGP SIGNATURE-----
On 14/02/2008, James Turnbull <james@lovedthanlost.net> wrote:> | a) Are you (Luke/James) interested in adding additional facts to the > | main facter tree or do you prefer that additional facts are kept out > | of the main tree? > > > Outside of the main tree is my preference.Unless sufficiently generic as your subsequent mail outlined. How about something simple like "kernelversion" which would give simply the nummeric part of a linux kernel version (2.6.18) ?> Breaking into smaller pieces is the planned direction. There is a > refactor that I have committed (pending Luke''s comment) to do exactly > this. The vast majority of facts will be split from facter.rb.Need help?> | c) Do you have any preferences in terms of fact naming? What to > | shorten, what not to shorten and so on? > > Happy to take discussion on this. Not overly fussed.Don''t really feel strongly about anything - it was just if something like that was already in place. As it''s not the case, I suggest we simply bring out the names and you then shot them down at will. ;-)> | d) Are the fact names supposed to be kept stable between versions? > | > > Yes - I think so to reduce potential for rewrite in people''s manifests. > ~ Do you see something different here and if so why? (curious rather than > antagonistic...)I fully agree - was contemplating making some kind of wrapper to ensure that I would always get consistent names, but that''s pretty pointless with your approach. Could we consider maybe adding a facter ABI version as a fact, which could be used to detect fact name changes? /peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Hoeg wrote: | On 14/02/2008, James Turnbull <james@lovedthanlost.net> wrote: | |> | a) Are you (Luke/James) interested in adding additional facts to the |> | main facter tree or do you prefer that additional facts are kept out |> | of the main tree? |> |> |> Outside of the main tree is my preference. | | Unless sufficiently generic as your subsequent mail outlined. How | about something simple like "kernelversion" which would give simply | the nummeric part of a linux kernel version (2.6.18) ? Sounds good. |> Breaking into smaller pieces is the planned direction. There is a |> refactor that I have committed (pending Luke''s comment) to do exactly |> this. The vast majority of facts will be split from facter.rb. | | Need help? Thanks but it''s pretty much done. | Don''t really feel strongly about anything - it was just if something | like that was already in place. As it''s not the case, I suggest we | simply bring out the names and you then shot them down at will. ;-) Sounds good. |> Yes - I think so to reduce potential for rewrite in people''s manifests. |> ~ Do you see something different here and if so why? (curious rather than |> antagonistic...) | | I fully agree - was contemplating making some kind of wrapper to | ensure that I would always get consistent names, but that''s pretty | pointless with your approach. Could we consider maybe adding a facter | ABI version as a fact, which could be used to detect fact name | changes? What do you mean by ABI? 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 iD8DBQFHtf/P9hTGvAxC30ARAohkAJ4i9+WEVWZFkZF79ByL98DWFnyxvACeJIQ9 ivlafeQkRSVexG8kIxc+/Xk=pp0o -----END PGP SIGNATURE-----
> | about something simple like "kernelversion" which would give simply > | the nummeric part of a linux kernel version (2.6.18) ? > > Sounds good.I''ll send you a patch. Do you want a git push?> | I fully agree - was contemplating making some kind of wrapper to > | ensure that I would always get consistent names, but that''s pretty > | pointless with your approach. Could we consider maybe adding a facter > | ABI version as a fact, which could be used to detect fact name > | changes? > > What do you mean by ABI?Sorry, meant API, and while it''s still a horrible way to describe what I mean, it was for the lack of a better word. Let''s say we define the current names as FACTER_NAMING_CONVENTION version 1. Using puppet you could then check for the value of this and select the names of choice based on it. It would allow you to change the names later if there ever was a need. Alternatively, you could tell facter which version you were requesting and get the corresponding names. Just a thought. /peter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Hoeg wrote: |> | about something simple like "kernelversion" which would give simply |> | the nummeric part of a linux kernel version (2.6.18) ? |> |> Sounds good. | | I''ll send you a patch. Do you want a git push? Patch is fine for now - my repo is in sadface conflict merge that I haven''t fixed yet. | Sorry, meant API, and while it''s still a horrible way to describe what | I mean, it was for the lack of a better word. Let''s say we define the | current names as FACTER_NAMING_CONVENTION version 1. Using puppet you | could then check for the value of this and select the names of choice | based on it. It would allow you to change the names later if there | ever was a need. Alternatively, you could tell facter which version | you were requesting and get the corresponding names. Oh I see. Umm let me think on that. Cheers James - -- 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 iD8DBQFHuYd69hTGvAxC30ARAplKAJ4r9WSh9cBvLQRYtPZJNHV7vmn07gCfa++q APu27koNj4yzUiqZz/enDiE=4Pu1 -----END PGP SIGNATURE-----
Hi, On 15 Feb 2008, at 21:10, James Turnbull wrote:> Peter Hoeg wrote: > | On 14/02/2008, James Turnbull <james@lovedthanlost.net> wrote: > |> Outside of the main tree is my preference. > | > | Unless sufficiently generic as your subsequent mail outlined. How > | about something simple like "kernelversion" which would give simply > | the nummeric part of a linux kernel version (2.6.18) ? > > Sounds good.That''s sufficiently generic for linux, but is the same true for all other platforms? On Solaris, for example, the kernel version will simply be "Generic" for the initial release of a new major revision (or, at least, that used to be the case), something different for the periodic updates to that major revision, and both will change when kernel patches are applied. Solaris 9, initial release: $ uname -a SunOS test1 5.9 Generic sun4u sparc SUNW,UltraAX-i2 Solaris 10, some release: $ uname -a SunOS test2 5.10 Generic_118822-30 sun4u sparc SUNW,UltraAX-i2 Solaris 10, some newer release: $ uname -a SunOS test3 5.10 Generic_120012-14 i86pc i386 i86pc (I apologise for not tracking which particular release each of the Sol10 installs is) Point being, I''d think that "the numeric part of a linux kernel version" is, by definition, platform-specific. Perhaps there''s a sensible plan to make this platform-neutral? Zac