Hi, A problem I''ve run into during my first attempts at writing manifests, is knowing what possible facts are available, and for a given fact, what values my manifest might encounter. A classic one is the possible values of $operatingsystem, but it applies to all sorts of facts. Of course, I know that not all facts can be enumerated, but I had expected there be a catalog of common facts and their values somewhere, but there seems not to be. The Facter page [1] and API documentation [2] give rather scanty information about anything, yet alone list any values. Ultimately I''ve been forced to search out the source code and infer the values from that. Then there is the question of how consistent the list of facts and their values are from version to version of Puppet/Facter. That is even harder to discover from the source code. How do other people tackle this problem? Thanks, N 1. http://www.puppetlabs.com/puppet-3/related-projects/facter/ 2. http://www.puppetlabs.com/downloads/facter/apidocs/ -- 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 Nov 21, 7:55 am, Nick <oinksoc...@letterboxes.org> wrote:> A problem I''ve run into during my first attempts at writing manifests, is > knowing what possible facts are available, and for a given fact, what values my > manifest might encounter.I use ''default'' matches liberally. For required values I throw an error or warning where a value isn''t found. Usually you can set a sane default inside the resource[1]: file { ''sshdconfig'': name => $operatingsystem ? { solaris => ''/usr/local/etc/ssh/sshd_config'', default => ''/etc/ssh/sshd_config'', }, } Or when the value must be known to get a functional catalog: class foo::client { case $operatingsystem { ''redhat'': { include foo::client::redhat } ''solaris'': { include foo::client::solaris } default: { fail( "unsupported operatingsystem \"$operatingsystem\" ")} } }> Of course, I know that not all facts can be enumerated, but I had expected there > be a catalog of common facts and their values somewhere, but there seems not to > be. The Facter page [1] and API documentation [2] give rather scanty > information about anything, yet alone list any values. Ultimately I''ve been > forced to search out the source code and infer the values from that.I''d suggest opening a ticket for the documentation. I think puppetlabs is making a push to improve the docs, but need tickets to prioritize work.> Then there is the question of how consistent the list of facts and their values > are from version to version of Puppet/Facter. That is even harder to discover > from the source code.I''ve been using puppet since .22 and I can''t recall any facts changing drastically. Usually its simply facts expanding to resolve more accurate data. [1] http://docs.puppetlabs.com/guides/language_tutorial.html -- 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, Nov 21, 2010 at 7:55 AM, Nick <oinksocket@letterboxes.org> wrote:> Hi, > > A problem I''ve run into during my first attempts at writing manifests, is > knowing what possible facts are available, and for a given fact, what values my > manifest might encounter. > > A classic one is the possible values of $operatingsystem, but it applies to all > sorts of facts. > > Of course, I know that not all facts can be enumerated, but I had expected there > be a catalog of common facts and their values somewhere, but there seems not to > be. The Facter page [1] and API documentation [2] give rather scanty > information about anything, yet alone list any values. Ultimately I''ve been > forced to search out the source code and infer the values from that. > > Then there is the question of how consistent the list of facts and their values > are from version to version of Puppet/Facter. That is even harder to discover > from the source code. > > How do other people tackle this problem? >It is straightforward to get a complete list of facter values in your environment. Here''s a ruby script that collects all facts gathered in puppet master /var/lib/puppet/yaml/facts directory and provide a summarized view: http://pastie.org/1317925. fact: {"value"=>"# of system reporting value"...} Sample output: facterversion: {"1.5.7"=>5, "1.5.1"=>10, "1.3.5"=>1} ... lsbdistid: {"Debian"=>6} lsbdistrelease: {"testing/unstable"=>2, "testing"=>3, "5.0.3"=>1} ... operatingsystem: {"Debian"=>11, "CentOS"=>5} ... It''s not pretty, but should give you all values in your environment. If the # of systems doesn''t add up, then it''s a fact that''s not present on some systems. In the example above there was 16 servers, but lsb* only have 6 server reporting, because lsb_release wasn''t install on all systems. Thanks, Nan -- 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 Nov 22, 12:18 pm, Nan Liu <n...@puppetlabs.com> wrote:> On Sun, Nov 21, 2010 at 7:55 AM, Nick <oinksoc...@letterboxes.org> wrote: > > A problem I''ve run into during my first attempts at writing manifests, is > > knowing what possible facts are available, and for a given fact, what values my > > manifest might encounter.[...]> It is straightforward to get a complete list of facter values in your > environment. Here''s a ruby script that collects all facts gathered in > puppet master /var/lib/puppet/yaml/facts directory and provide a > summarized view:http://pastie.org/1317925.If you don''t already have Puppet running on some of your systems of interest, or if you''re interested in the facts for a specific machine, then you can always run facter from the command line. It will output the facts it discovers on that system. John -- 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 21 November 2010 15:55, Nick <oinksocket@letterboxes.org> wrote:> Hi, > > A problem I''ve run into during my first attempts at writing manifests, is > knowing what possible facts are available, and for a given fact, what values my > manifest might encounter. > > A classic one is the possible values of $operatingsystem, but it applies to all > sorts of facts. > > Of course, I know that not all facts can be enumerated, but I had expected there > be a catalog of common facts and their values somewhere, but there seems not to > be. The Facter page [1] and API documentation [2] give rather scanty > information about anything, yet alone list any values. Ultimately I''ve been > forced to search out the source code and infer the values from that.This is a good point and certainly an area we can improve on. To that end I''ve filed https://projects.puppetlabs.com/issues/5394> Then there is the question of how consistent the list of facts and their values > are from version to version of Puppet/Facter. That is even harder to discover > from the source code.This will get better in the future (tm) but will involve breaking compatibility backwards as we currently have some ill-defined and overlapping facts that don''t have a consistent world view and as such attempts to "correct" them in the past have caused sites to break - eg domainname. We do try to avoid regressions in facts, but this has grown quite hard in some areas and prevented clarification due to ambiguities. What a particular fact name means should be much more apparent, visible and documented.> How do other people tackle this problem?For the most part you have a few options when first introducing puppet - run facter manually on your systems as part of a learning exercise, run in no-op mode for a bit and get to understand it''s naming. In some cases sites have written custom facts to either override the supplied facts or complement them to give them the consistency you need.> 2. http://www.puppetlabs.com/downloads/facter/apidocs/I''m not sure how much value those API docs are at the moment as facts are littered alongside library routines and there isn''t much of a coherent whole. 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.
Thank you Paul, and thank you everyone else for your replies. Presumably fact values can be broken down into two categories: a) those values which exist in Factor''s code base somewhere b) those values which are obtained from elsewhere Those in a) can be deduced just by looking at the Factor codebase. Those in b) cannot, in general. Even those values those in a), most will be emitted depending on some criteria obtained from the environment. Not much point, otherwise. This means that although they can be listed as ''possible'' it may not always be able to say when. Therefore, to really know what values are possible, and what systems they are associated with - and equally importantly, to spot anomalies - I imagine one would need to survey many different machines (as well as inspect the Facter code base). Maybe Puppet Labs is already collecting this information? If not, would seem a useful goal. PL''s clients would be one source, but I''m wondering if there''s also some way to gather the information from the community. To this end, perhaps contributions of fact information could be made easier if there were an (anonymising?) fact-reporting tool, perhaps incorporating ideas from Nan Liu''s script. Users could then use it a part of a bug-report, or request for help, or just to contribute to the community database. (Thinking of a compelling incentive to contribute is difficult, but even so, the possibility to do it needs to exist first.) Unfortunately I don''t have the resources to volunteer to create such a thing, but possibly the idea is worth adding to the comments of the ticket. Cheers, N -- 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.