> On 2 Mar 2016, at 21:16, Trevor Vaughan <[email protected]> wrote: > > 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.
Not specifically. Types already have doc strings similar would be enough for this. > > 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. >>>>> 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. >>>> >>>> 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. >>> 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. >> >> 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. -- 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/9BBF169A-FE92-4FE2-B7A5-9A4795DAD8FD%40devco.net. For more options, visit https://groups.google.com/d/optout.
