A config file for facter is intriguing to me.Would this solely be used to change behaviors when running facter, or do you see some potential for defining some facts within the config itself?
Also, would you move facter specific configs into this facter.conf instead of being managed from the puppet.conf file (ie: cfacter, factpath, fact_terminus)?
The only problem I sometimes encounter, which may be a usage issue on my part, is when creating custom facts sometimes it'd be nice to just run `facter my_custom_fact` to get the output. If there would be some way to register custom facts so that facter picks them up without having to run puppet or run the ruby code the custom fact is in manually, that would be interesting. If that already exists I haven't found how to do that.Either way, I think a config where you can either specify which facts to enable or disable would be useful.
On Tuesday, March 1, 2016 at 11:52:12 AM UTC-7, Eric Sorenson 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)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.--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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/0f42fe6f-1f75-4aff-aa6a-77dd3e17235c%40googlegroups.com.
On Mar 1, 2016, at 12:25 PM, Matthew Gaspar <gat...@gmail.com> wrote:A config file for facter is intriguing to me.Would this solely be used to change behaviors when running facter, or do you see some potential for defining some facts within the config itself?
Also, would you move facter specific configs into this facter.conf instead of being managed from the puppet.conf file (ie: cfacter, factpath, fact_terminus)?
The only problem I sometimes encounter, which may be a usage issue on my part, is when creating custom facts sometimes it'd be nice to just run `facter my_custom_fact` to get the output. If there would be some way to register custom facts so that facter picks them up without having to run puppet or run the ruby code the custom fact is in manually, that would be interesting. If that already exists I haven't found how to do that.
Either way, I think a config where you can either specify which facts to enable or disable would be useful.
----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+...@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.
The only problem I sometimes encounter, which may be a usage issue on my part, is when creating custom facts sometimes it'd be nice to just run `facter my_custom_fact` to get the output. If there would be some way to register custom facts so that facter picks them up without having to run puppet or run the ruby code the custom fact is in manually, that would be interesting. If that already exists I haven't found how to do that.
Either way, I think a config where you can either specify which facts to enable or disable would be useful.
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)
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
- ec2 facts IP address to hit
- default gateway device- override some paths to required binaries
Etc, tons of these. So some way that we all agree on to ingest config on a per fact basis
------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+...@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+...@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.
On Tuesday, March 1, 2016, Matthew Gaspar <gat...@gmail.com> wrote:The only problem I sometimes encounter, which may be a usage issue on my part, is when creating custom facts sometimes it'd be nice to just run `facter my_custom_fact` to get the output. If there would be some way to register custom facts so that facter picks them up without having to run puppet or run the ruby code the custom fact is in manually, that would be interesting. If that already exists I haven't found how to do that.This probably isn't in scope for this, but the above is my most highly sought after goal.
Either way, I think a config where you can either specify which facts to enable or disable would be useful.We manage firewalls and routers as well as server OSes and it would be nice to flag which facts shouldn't cause errors on every run on those nodes.
I would suggest this information should be available locally AND/OR through the master/agent mechanism somehow - please don't require yet another file{} resource for puppet related settings in every node's manifest.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT-eEdup-%3DM2jJH-8-_GFj4EywQjX%2BihaS%2BLhgC8_9di_g%40mail.gmail.com.
Does 'facter -p my_custom_fact' do the trick here?
Ah yeah, I've heard this a few times as well. But why is it more of a thing on firewalls/routers?
Is the concern here about manifest bloat?
On Tue, Mar 1, 2016 at 3:13 PM, R.I.Pienaar <r...@devco.net> 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 factAh 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 hitSorry, naive question but I thought the ec2 metadata address was always the same? It's hardwired in facter today.
- default gateway device- override some paths to required binariesWhat 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?
Etc, tons of these. So some way that we all agree on to ingest config on a per fact basisI like the idea in general, and would love to get more color on the spectrum of use cases, hence the questions above.
--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+...@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+...@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.--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALsUZFEZ8arhPooYuv_%2BriofhQnM74aZzG5ZUG0G8cd%3DoscEfA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/C15C5276-E40B-49F0-93EC-FA9087AEE5A3%40devco.net.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWw3d9B%2BAfvA5NL8gLp%2BH7-OgbiLDqcw318okz6Nc6nnQ%40mail.gmail.com.
- /usr/lib/systemd/system/
- /etc/systemd/system
- /etc/systemd/system.d/${unit}.d/*.conf (does not override, but provides the possibility to add settings)
- /run/systemd/system