On Mon, Sep 23, 2013 at 11:56 AM, John Julien <[email protected]> wrote:
> Andy, thanks for getting the brainstorm going. I've attempted to address > each item below. > Yeah, great brainstorm session. A few more comments below. > On Monday, September 23, 2013 11:38:25 AM UTC-5, Andy Parker wrote: > >> 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. > > This does seem like a case of choosing the lesser evil. I don't like #1 because I don't like silently swallowing failures. This would mean masking "real" failures and thus making diagnosis difficult. I'd vote for #2, or actually I'd extend it something like per-kernel subdirectories (linux/windows/darwin/etc). So completely cross-platform facts would be in "facts/" but linux-specific ones in "facts/linux/", etc. This isn't the most elegant solution but I'm not coming up with an option 3 yet ... :) > >>> 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 like Andy's idea of deprecating 'facter --puppet' but yeah we should think about the timeline for that deprecation. 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 also assume/hope that people aren't running significantly different vintages of puppet and facter. But I assume you mean to bump the facter version in puppet's Gemfile; that would make sense to me. Kylo -- 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.
