On Mon, Sep 23, 2013 at 7:56 AM, John Julien <[email protected]> wrote:
> 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]>wrote: >> >>> I'd like to start some discussion around how to implement >>> https://projects.puppetlabs.**com/issues/9546<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 > Perfect explanation and justification for this feature :) Thanks for providing that. > > > *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. > -- Andrew Parker [email protected] Freenode: zaphod42 Twitter: @aparker42 Software Developer *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.
