Is there a repository of Facter plugins that people have made? I''m working on a few that i wouldn''t mind sharing when complete.
Digant C Kasundra wrote:> Is there a repository of Facter plugins that people have made? I''m working > on a few that i wouldn''t mind sharing when complete.Shouldn''t these plugins just be merged into facter (assuming they''re implemented cleanly)? -- Russell A. Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield Personifiers of the world, unite! You have nothing to lose but Mr. Dignity! -- Bernadette Bosky _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
--On Wednesday, April 25, 2007 6:30 PM -0700 Russell Jackson <raj@csub.edu> wrote:> Digant C Kasundra wrote: >> Is there a repository of Facter plugins that people have made? I''m >> working on a few that i wouldn''t mind sharing when complete. > > Shouldn''t these plugins just be merged into facter (assuming they''re > implemented cleanly)?Not necessarily. They may not be things everyone wants or cares about. For instance, as a practice exercise in Ruby, I wrote one that grabs the Serial Number and Manufacturer information out of dmidecode.
> Not necessarily. They may not be things everyone wants or cares about. > For instance, as a practice exercise in Ruby, I wrote one that grabs the > Serial Number and Manufacturer information out of dmidecode. >I think a set of comprehensive facts that one could use to perform comprehensive inventory of managed machines would be very useful.
On Wed, Apr 25, 2007 at 03:18:56PM -0700, Digant C Kasundra wrote :> Is there a repository of Facter plugins that people have made? I''m working > on a few that i wouldn''t mind sharing when complete.Well I am using the wiki with the facter + recipe keywords. http://www.reductivelabs.com/trac/puppet/tags/facter%2Crecipe And I am adding with those keywords. Is there a plan for a Facter PRM ? david
On Thu, Apr 26, 2007 at 09:52:14AM +0200, David Vernazobres wrote:> On Wed, Apr 25, 2007 at 03:18:56PM -0700, Digant C Kasundra wrote : > > Is there a repository of Facter plugins that people have made? I''m working > > on a few that i wouldn''t mind sharing when complete. > > Well I am using the wiki with the facter + recipe keywords. > http://www.reductivelabs.com/trac/puppet/tags/facter%2Crecipe > And I am adding with those keywords. > > Is there a plan for a Facter PRM ?Speaking only for myself, I don''t think that facts quite warrant a whole PRM-style infrastructure. A few wiki pages and agressive inclusion in the main distribution of Facter (which I''m all in favour of, even if a lot of the facts aren''t of massive use to most platforms -- hell, that''s what confine() is for!) seems far more useful to me. Assuming nobody has any useful objections, I''ll happily review and apply patches to the facter tree for new facts (if I''ve got a facter commit bit, which I think I do). - Matt -- Java. The elegant simplicity of C++. The blazing speed of Smalltalk. -- From http://c2.com/cgi/wiki?SmalltalkMinusMinus
On Apr 26, 2007, at 5:18 AM, Matt Palmer wrote:> > Speaking only for myself, I don''t think that facts quite warrant a > whole > PRM-style infrastructure. A few wiki pages and agressive inclusion > in the > main distribution of Facter (which I''m all in favour of, even if a > lot of > the facts aren''t of massive use to most platforms -- hell, that''s what > confine() is for!) seems far more useful to me.I agree with the basic idea of having as many facts as possible in the main distribution, although at some point we''re going to need better debugging so people can list what facts exist, which ones are suitable, and which ones actually provide answers. As the number of facts scales, this information will become more important, and Facter will either become a much more comprehensive collection utility or will be phased out for an even more comprehensive utility.> Assuming nobody has any useful objections, I''ll happily review and > apply > patches to the facter tree for new facts (if I''ve got a facter > commit bit, > which I think I do).All Puppet committers automagically get commit access to Facter, so you do have it. -- Never interrupt your enemy when he is making a mistake. --Napolean Bonaparte --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Apr 26, 2007, at 5:18 AM, Matt Palmer wrote:> > Speaking only for myself, I don''t think that facts quite warrant a > whole > PRM-style infrastructure. A few wiki pages and agressive inclusion > in the > main distribution of Facter (which I''m all in favour of, even if a > lot of > the facts aren''t of massive use to most platforms -- hell, that''s what > confine() is for!) seems far more useful to me.Oh, and for the record -- I kinda do want something akin to PRM for Facter; or at least, some simple place for people to publish their Facts. Even something ad-hoc like TracHacks or Nagios''s Plugins would be a good start; we could just start sticking them on the Facter wiki, like we''re putting Puppet recipes on the Puppet wiki, but I know that won''t scale all that well, since wiki text isn''t managed like code. -- The easiest way for your children to learn about money is for you not to have any. -- Katharine Whitehorn --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
How much will an overabundance of facts in Facter slow Puppet down? I.e. if I want to find all of the packages installed on my system, it could be expensive to run every time. Would it be possible to do some sort of pre-hashing of the Puppet manifest variables to determine exactly which ones need to be pulled at run time? Or, does Puppet already just query Facter by name if it can''t find an internal definition. Also, should you prefix Facter specific variables in Puppet with something like ''facter_''? As you add more definitions you run the risk of name space collision with already developed manifests. Trevor On 4/26/07, Luke Kanies <luke@madstop.com> wrote:> > On Apr 26, 2007, at 5:18 AM, Matt Palmer wrote: > > > > Speaking only for myself, I don''t think that facts quite warrant a > > whole > > PRM-style infrastructure. A few wiki pages and agressive inclusion > > in the > > main distribution of Facter (which I''m all in favour of, even if a > > lot of > > the facts aren''t of massive use to most platforms -- hell, that''s what > > confine() is for!) seems far more useful to me. > > Oh, and for the record -- I kinda do want something akin to PRM for > Facter; or at least, some simple place for people to publish their > Facts. Even something ad-hoc like TracHacks or Nagios''s Plugins > would be a good start; we could just start sticking them on the > Facter wiki, like we''re putting Puppet recipes on the Puppet wiki, > but I know that won''t scale all that well, since wiki text isn''t > managed like code. > > -- > The easiest way for your children to learn about money is for you > not to have any. -- Katharine Whitehorn > --------------------------------------------------------------------- > Luke Kanies | http://reductivelabs.com | http://madstop.com > > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Apr 26, 2007, at 12:08 PM, Trevor Vaughan wrote:> How much will an overabundance of facts in Facter slow Puppet down?Well, it will slow it down by the amount of time it takes to retrieve all of those facts.> I.e. if I want to find all of the packages installed on my system, > it could be expensive to run every time.Yep.> Would it be possible to do some sort of pre-hashing of the Puppet > manifest variables to determine exactly which ones need to be > pulled at run time? Or, does Puppet already just query Facter by > name if it can''t find an internal definition.All facts are collected by the client before ever contacting the server, and the compiler cannot know what facts would be used, so there''s no real way to do optimizations here.> Also, should you prefix Facter specific variables in Puppet with > something like ''facter_''? As you add more definitions you run the > risk of name space collision with already developed manifests.Yep. I expect that I''ll add hashes at some point and put all of the Facter facts into a global, constant hash. I''m opposed to using prefixes, though. -- A bore is a man who deprives you of solitude without providing you with company. -- Gian Vincenzo Gravina --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
> > Not necessarily. They may not be things everyone wants or > cares about. > > For instance, as a practice exercise in Ruby, I wrote one > that grabs > > the Serial Number and Manufacturer information out of dmidecode. > > I think a set of comprehensive facts that one could use to > perform comprehensive inventory of managed machines would be > very useful.I tend to agree. Particularly if it''s easy to add and remove custom facts that you do/don''t need. ********************************************************************************* Important Note This email (including any attachments) contains information which is confidential and may be subject to legal privilege. If you are not the intended recipient you must not use, distribute or copy this email. If you have received this email in error please notify the sender immediately and delete this email. Any views expressed in this email are not necessarily the views of AXA-Tech Australia. Thank you. **********************************************************************************
--On Thursday, April 26, 2007 12:53:57 -0500 Luke Kanies <luke@madstop.com> wrote:>> How much will an overabundance of facts in Facter slow Puppet down? > > Well, it will slow it down by the amount of time it takes to retrieve > all of those facts.Maybe there should be a facter config file that states which facts to run or not run? I can certainly see facts being added or desired by some not being desired by others, and needing some modular way to add/remove them or enable/disable them.
On May 1, 2007, at 6:14 PM, Digant C Kasundra wrote:> > Maybe there should be a facter config file that states which facts > to run > or not run? I can certainly see facts being added or desired by > some not > being desired by others, and needing some modular way to add/remove > them or > enable/disable them.My plan for this has been to tag the facts, and pick facts based on those tags. E.g., Puppet could just evaluate the facts tagged with ''system'' or something like that. -- The conception of two people living together for twenty-five years without having a cross word suggests a lack of spirit only to be admired in sheep. --Alan Patrick Herbert --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com