> On 2 Mar 2016, at 03:45, Kylo Ginsberg <k...@puppetlabs.com> wrote: > >> On Tue, Mar 1, 2016 at 3:13 PM, R.I.Pienaar <r...@devco.net> wrote: >> >> >>> On 1 Mar 2016, at 19:52, Eric Sorenson <eric.soren...@puppetlabs.com> 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 puppet-dev+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/puppet-dev/6b93869b-83b3-43dc-8784-bd2cf173e54c%40googlegroups.com. >>> 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 puppet-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/3C1D9D77-61CF-49A1-90AB-E7277BB9B636%40devco.net. >> >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Kylo Ginsberg | k...@puppetlabs.com | 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 puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CALsUZFEZ8arhPooYuv_%2BriofhQnM74aZzG5ZUG0G8cd%3DoscEfA%40mail.gmail.com. > 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/C15C5276-E40B-49F0-93EC-FA9087AEE5A3%40devco.net. For more options, visit https://groups.google.com/d/optout.
