On Monday, September 23, 2013 4:29:35 AM UTC-5, Andy Parker wrote: > > On Sat, Sep 21, 2013 at 1:00 PM, John Julien > <[email protected]<javascript:> > > wrote: > >> I'd like to start some discussion around how to implement >> https://projects.puppetlabs.com/issues/9546 (Plugin sync support for >> external facts) >> >> > That issue unfortunately only states that it should do it, but nothing > about why we should do it. I had always thought that external facts were > for things that are outside of the normal puppet process (information left > by the provisioning tool, for instance), in which case copying them from > the master isn't useful. > > So I guess my first question is, what scenarios do we need to support that > aren't handled right now (or handled in a very clumsy way)? >
Right now if a person is using an external fact that is fully puppet controlled they are creating a file resource in Puppet to get it to the client. This means the fact won't actually be available during the catalog compile until the 2nd Puppet run. It usually causes errors in the 1st Puppet run or undesired behavior around the portion of code that requires that fact. This is quite clumsy and for this reason I try to encourage everyone to write their facts in Ruby, especially if they are one liner commands because you really don't need to even know ruby to write those. My team is full of sysadmins who all know shell, some know a little python or perl and fewer know ruby. So most desire to write their facts in a language they already know. We also have application owners writing Puppet modules. An example here would be apache. We have apache admins who need to get facts deployed to their systems and they are even less familiar with python and perl and only know a little shell. This makes external facts very attractive to them. If you asked my co-workers they would say "John doesn't like external facts" but the reality is I don't dis-like the concept, I dis-like the implementation. Putting them in plugin-sync cleans up the implementation. I support external facts because it broadens the use of Puppet at my organization. It brings Puppet one step closer to a level people already understand and they then feel they can use it. I have found that the concept of Puppet itself confuses people who are used to doing things in shell scripts. I was the same way the first time it was explained to me, it's a lot to take in at once when you are so used to a linear flow of commands being executed with a few if/then/else. When I'm explaining Puppet to people and mention writing facts in ruby their eyes just gloss over even more. My motivation is to get as many people as I can using Puppet to make all of our lives easier, and if that mean's I have to dangle a carrot in front of them (external facts) then so be it. I also found this blog by Kelsey which kind of re-iterates what I said about opening up fact writing to more people. http://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3 *"The Facter Ruby API is the standard way of creating custom facts, which sets the bar pretty high for creating new facts. facter-dot-d lowers the bar significantly by adding the ability to use flat files as well as scripts in any language to produce custom facts. This is a huge win for people just getting started and for people who have existing data they would like to use as Facts." - Kelsey Hightower * he Facter Ruby API is the standard way of creating custom facts, which sets the bar pretty high for creating new facts - See more at: http://puppetlabs.com/blog/module-of-the-week-puppetlabsstdlib-puppetlabs-standard-library-part-3#sthash.MP18SKN4.dpuf *Join us at PuppetConf 2014, September 23-24 in San Francisco* > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev. For more options, visit https://groups.google.com/groups/opt_out.
