On Tue, Sep 24, 2013 at 6:24 AM, Kylo Ginsberg <[email protected]> wrote:
> 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 ... :) > > A third option is that an external fact has an optional metadata file (myfacts.sh and myfacts.meta). That file can describe things like: * What facts do you expect to get out of the script * What confines the script has * Maybe a description of it? I encountered this same question when I played around with a rewrite of facter (https://github.com/zaphod42/facter-rewrite) in which everything was an external fact. I didn't implement this, but it was what I was thinking of at the time. The confines can be expressed either as an s-expression style or a small language: { "confine": ["and", ["=", "osfamily", "RedHat"], ["=~", "kernelversion", "2\.6"]] } In this manner, puppet syncs down all of these files (scripts and metadata), but facter decides what to run and what not to. > >>>> 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. > > Yeah, as long as --puppet is there we need to make sure it works. I was just planting the seed of an idea of getting rid of it. > 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. > Gemfile and the various packages that we produce. > > 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. > -- 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.
