R.I., did I just hear you make a suggestion for writing fact DDL files? Not sure how I feel about that, they're a pain to deal with and confuse users.
The features that I would like to add my vote for: * Fact TTLs * Custom fact execution timeouts * Fact execution timeouts * Fact parallelization (and settings therein) * Moving the facts.d location * Asynchronous fact reporting (I don't want to have to run facter every puppet run) * System fact ACLs (have the ability to allow other hosts access to facts) Thanks, Trevor On Wed, Mar 2, 2016 at 1:07 AM, R.I.Pienaar <[email protected]> wrote: > > On 2 Mar 2016, at 03:45, Kylo Ginsberg <[email protected]> wrote: > > On Tue, Mar 1, 2016 at 3:13 PM, R.I.Pienaar <[email protected]> wrote: > >> >> >> On 1 Mar 2016, at 19:52, Eric Sorenson <[email protected]> >> wrote: >> >> I've been thinking about a config file for Facter, which has historically >> not been run-time configurable. >> >> The two problems in front of me that seem applicable are: >> >> * Sometimes, certain facts are just plain bad to collect and users would >> like to prevent them from even being resolved (see FACT-718, FACT-449, ). >> * Some facts are not inherently bad but _are_ expensive and/or change >> infrequently, so preventing them from being resolved every time would be >> beneficial (FACT-348) >> >> > One question I'm curious to get feedback on is whether such a blacklist > (or whitelist?) of facts would be at the top-level-structured-fact basis, > or whether there are compelling use case for it to be more fine-grained. > > The per-top-level-structured fact basis would have some nice attributes: > * it's simpler (good unless it's too simple) > * given that one of the goals in skipping some facts, that would align > pretty nicely with the facter 'resolvers' - whereas to support fine-grained > blacklisting of facts might still require *collecting* all the facts, and > just blacklisting at the point of return/reporting. > > Similar question (but may not be the same answer) for fact ttl's. Also for > fact ttl's, I'd think we could provide some useful defaults, e.g. osfamily > doesn't change during process lifetime, that sort of thing. > > I'd be curious for comments on any of the above. > > >> Are there other problems you're running into in this area that you'd like >> to see addressed with a "facter.conf"? I'd like to gather all the >> requirements and start up a little Puppet RFC based on them. >> >> >> >> Some individual facts might benefit from configuration. >> >> - never consider docker*,and,others for ipaddress fact >> > > Ah yes, that makes sense. We've had a few requests for fine-tuning > ipaddress fact collection that could possibly be met by a regex along those > lines. > > - ec2 facts IP address to hit >> > > Sorry, naive question but I thought the ec2 metadata address was always > the same? It's hardwired in facter today. > > > You get proxies and caches and compatible services for other clouds. Along > the same lines I know in the past the fact checked some hard coded MAC > address this could be a good target > > > >> - default gateway device >> - override some paths to required binaries >> > > What are some of the example use cases for overriding path to binaries? > Are there use cases for overriding path to some of the non-binary files > that facter processes? > > > People who install hand compiled software for example. Not exactly a path > but kind of analogous people who write custom facts that uses internal > APIs, these might need pointing to different places in different > environments > > > >> Etc, tons of these. So some way that we all agree on to ingest config on >> a per fact basis >> > > I like the idea in general, and would love to get more color on the > spectrum of use cases, hence the questions above. > > > Yeah so my list is more hypothetical than actual I Have These Problems but > certainly seen some of these on IRC and the class of feature has many uses > > It is though a very difficult feature because you might need to config > this at plugin sync time and plugin sync is too dumb to have any kind of > selection logic ie. to put different configs on different hosts or template > bake configs etc. Whenever I have thought of requesting this feature I > always end up needing this part and I think logic in plugin sync would be > bad. > > Additionally surfacing the available configs for a fact in a user > consumable way that also supports custom facts could be a pain. I have > often felt though that facts need to support doc strings that can be > queried via the CLI etc, that might help a lot if we go this route - and in > general I think would be a hugely helpful thing. > > > Kylo > > >> >> >> >> --eric0 >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/6b93869b-83b3-43dc-8784-bd2cf173e54c%40googlegroups.com >> <https://groups.google.com/d/msgid/puppet-dev/6b93869b-83b3-43dc-8784-bd2cf173e54c%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> >> -- >> 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 view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/3C1D9D77-61CF-49A1-90AB-E7277BB9B636%40devco.net >> <https://groups.google.com/d/msgid/puppet-dev/3C1D9D77-61CF-49A1-90AB-E7277BB9B636%40devco.net?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Kylo Ginsberg | [email protected] | irc: kylo | twitter: @kylog > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CALsUZFEZ8arhPooYuv_%2BriofhQnM74aZzG5ZUG0G8cd%3DoscEfA%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CALsUZFEZ8arhPooYuv_%2BriofhQnM74aZzG5ZUG0G8cd%3DoscEfA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/C15C5276-E40B-49F0-93EC-FA9087AEE5A3%40devco.net > <https://groups.google.com/d/msgid/puppet-dev/C15C5276-E40B-49F0-93EC-FA9087AEE5A3%40devco.net?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWw3d9B%2BAfvA5NL8gLp%2BH7-OgbiLDqcw318okz6Nc6nnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
