Andy, thanks for getting the brainstorm going. I've attempted to address each item below.
On Monday, September 23, 2013 11:38:25 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) >> >> Since external facts can be any type of executable and additionally >> straight json and yaml, i'm not sure putting then under lib/ is the best >> place to make the pluginsync magic happen. I was thinking it might make >> sense to add an extfact/ directory to the module structure that gets >> synchronized to $vardir/extfact which is then added to facters directory >> loader during the puppet run. >> >> > I think that sounds like the right approach. Is there a case where we > shouldn't copy certain external facts to a machine because either they > won't work or they would be unsafe (I'm specifically thinking windows vs > unix type things)? Based on the reasoning that you gave, maybe calling the > directories simply "facts/" and "$vardir/facts" would be better to promote > those as the way of adding new facts. > > That's a great question. I'm not sure I have an awesome answer for it either. Here are a few initial options. I'm hoping someone has an option 3 or 4 to share. 1 - Facter is re-written to silently fail on external facts. This should pretty well ensure windows facts don't show up on unix and unix doesn't show up on windows. 2 - We create a directory structure for syncing facts. One for windows and one for unix. I don't really like option 2 at all because for 1 it just feels dirty and 2ndly it doesn't really guarantee we won't have incompatible facts. Take for example someone writing their fact in python requiring a module that isn't installed on a system. That fact may have been written for a unix os but it'll still fail when running on one. So, I'd vote for option 1 here, but again I'm hoping someone has an option 3 or 4 in mind because I'm not quite sold. > So that's how to get the plugin magic to happen, now about providing >> expected results for facter. If a user has external facts that are being >> synced with puppet, they are going to probably expect "facter --puppet" to >> show those facts. So that's an update to load_puppet in facter. >> >> > Yep. > > On a side question, should facter deprecate the "--puppet" option and > instead we should fix up "puppet facts" to be more useful? That has the > deployment advantage of removing the dependency cycle between puppet and > facter and I think for new users would make more sense (why do I have to > run facter to see what the puppet facts are?). > If we deprecated the --puppet on facter, would we still incorporate the puppet external config directories into facter so that they are available until v2.0.x? I looked at the facter code this weekend and incorporating should be very trivial. I had to make a tweak to the facter code in preperation for adding the external facts in the puppet run. So, we've already bumped the facter version required there. I'm still waiting on it to be merged but you can read about it here https://projects.puppetlabs.com/issues/22636. I think we could add the appropriate facter --puppet code so that it is both forward and backward compatible with puppets external fact support. Puppet requiring version X of facter is the strict dependency as discussed below. > > >> There's also then the question of compatibility. External facts were not >> supported in facter until 1.7. Is there currently a compatibility >> relationship between puppet and facter, or would this be the first one? >> What's the best way to handle this? Hard code the pluginsync to provide a >> warning that external facts will not be available until they upgrade to >> facter 1.7+? >> >> > I would expect that anyone running a puppet that has this feature would > also be running a new facter. Is it a common occurrence to update puppet > but not facter? It is also possible that puppet just increases the version > of puppet it needs to >= 1.7.0. > I suppose I've never paid much attention to my version of facter. How are dependencies expressed today? I am most familiar with Red Hat and I know dependencies for specific facter versions are being placed on the RPMs. Would this version dependency all be handled at the packaging level, and thus assumed to be OK inside the puppet code? -- 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.
