The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #11449

Facter should have a configuration file

Added by Adrien Thebo over 4 years ago. Updated over 2 years ago.

Status:Needs DecisionStart date:12/16/2011
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Keywords: Affected Facter version:
Branch:

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

There are increasing cases where facts need more variability or customizability than what is currently possible. Adding a configuration file that would allow people to make site-specific customizations, or enable/disable facts, or other such modifications would make facter more powerful and flexible.


Related issues

Blocks Facter - Bug #11031: capturing ec2 userdata as a fact may be a security risk Investigating 11/23/2011
Blocks Facter - Feature #2059: Exclude certain facts from executing Accepted 03/09/2009

History

#1 Updated by Ken Barber over 4 years ago

  • Target version set to 186

I’m not sure – but this might be needed for 1.7.x, so lets place it there for now (better then leaving the target blank).

#2 Updated by Anonymous over 4 years ago

Ken Barber wrote:

I’m not sure – but this might be needed for 1.7.x, so lets place it there for now (better then leaving the target blank).

FWIW, I wouldn’t expect to see a solution to this ticket until it was part of a branch that added a consumer of that configuration file; since it isn’t currently related to any tickets that need configuration to be added, I would have said “unscheduled” was the best state for this. (Specifically, “unscheduled, waiting for a use case before we add the code”)

#3 Updated by Ken Barber over 4 years ago

  • Status changed from Accepted to Needs Decision
  • Target version deleted (186)

Yeah you’re right – its more in a ‘Needs Decision’ kind of stage anyway.

#4 Updated by Michael Knox over 4 years ago

The need to allow user input customisation of a fact is a major discussion for the mountpoint fact (#2847). In that case the debate is about how to provide customisations for a default ‘ignore’ array.

If the customisations are applied via a local config then I need to ensure that they are in place and up-to date before the Puppet run, thus creating a chicken & egg problem. I would prefer to be able to specify customisations through the Puppet DSL as this keeps everything in a central place. That said, local config files is probably the easiest way to ensure that customisations are available to most/all other consumers of facter data such as MCollective etc.

#5 Updated by Anonymous over 4 years ago

Michael Knox wrote:

The need to allow user input customisation of a fact is a major discussion for the mountpoint fact (#2847). In that case the debate is about how to provide customisations for a default ‘ignore’ array.

Michael, thanks – that is exactly the sort of use case we need to justify this being done.

#6 Updated by Adrien Thebo over 4 years ago

Another example of how a config file would be useful would be the ability to blacklist facts, to prevent them either from being run, or uploaded to the server, in the case of sensitive facts.

#7 Updated by Adrien Thebo over 4 years ago

Michael Knox wrote:

I would prefer to be able to specify customisations through the Puppet DSL as this keeps everything in a central place.

Currently, the design of Puppet doesn’t make this possible. Right now, facts are uploaded at the beginning of the Puppet run, and a catalog is then generated and returned, and there’s no way to configure facts and force a second upload. It would be nice to have this more self contained, but I don’t see any solution to configuring facts with puppet without two runs.

#8 Updated by Anonymous over 4 years ago

Adrien Thebo wrote:

Another example of how a config file would be useful would be the ability to blacklist facts, to prevent them either from being run, or uploaded to the server, in the case of sensitive facts.

Awesome. Can you link this ticket as a blocker, also, of that other ticket, then? That ties together the features in an easy to understand way, and makes sure we know what the blockers on getting something done are. :)

#9 Updated by Adrien Thebo over 4 years ago

Done, I wasn’t sure if that ticket was publicly viewable.

#10 Updated by Russell Miller about 3 years ago

One thing that facter also does not appear to do is allow a custom puppet config dir – it demands that it exist in /etc/puppet and there appears to be no way to change that. This means that nonstandard vardirs can’t be used unless FACTERLIB is set, which I think is entirely unreasonable.

Also available in: Atom PDF