The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Plugin sync support for external facts
|Affected Puppet version:||Branch:|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
So now we have external facts (#2157) we would want to be able to synchronise these somehow using pluginsync.
#3 Updated by Ken Barber over 4 years ago
Nigel Kersten wrote:
I totally agree we should be able to sync them somehow… but I note we’ve just committed a change to only pluginsync .rb files…
Your talking about #4135? It will still sync other files – just won’t load them. This is definitely a precursor to this ticket (hence why its on the dependency list). So its all good :–).
#7 Updated by R.I. Pienaar over 4 years ago
Nigel Kersten wrote:
Hrm. Now that’s a little more problematic…
I know, I consider it a personal challenge to keep your life interesting :P
RI, do you think a client-side filter is sufficient or does this control need to be mandated centrally?
hmm, i can’t think of a reason client side wouldnt be ok right now, but will give it some more thought – however imagine a big site with lots of facts unique to hsots etc, we could be doing a lot of file copies down to the client – and file copies are slow as heck.
#11 Updated by Knight Samar over 2 years ago
Can’t we leave the problem of putting the right fact on the right host, to the Puppet user ? Or to be more specific, the problem of the fact doing the right thing on a host
For example, if I am writing a piece of Python code which generates a fact, I should take care that it does the right thing on the right host, just like I would do in a Ruby custom fact.
At least support for .py and other such external executable, can be added.
#12 Updated by John Julien over 2 years ago
Capturing a discussion from the mailing list on this topic. There were 3 questions discussed about the implementation of this feature, see the details below.
Question 1: What is the justification for this feature? Why is it needed? Right now if a person is using an external fact that is fully puppet controlled they are creating a file resource in Puppet to get it to the client. This means the fact won’t actually be available during the catalog compile until the 2nd Puppet run. It usually causes errors in the 1st Puppet run or undesired behavior around the portion of code that requires that fact. This is a clumsy implementation.
Many people using Puppet are sysadmins who all are very familiar with shell, probably some python and perl in there too. Ruby is not as common of a language in the sysadmin tool box. Allowing users to write facts in a language they already know brings Puppet one step closer to a level people already understand which increases the adoption rate.
Question 2: Where will the external facts reside in the module path? The external facts will reside in a facts.d/ directory at the base of the module. So an example tree would be:
mymodule ├── facts.d │ └── my_external_fact.sh ├── lib │ └── facter │ └── custom_ruby_fact.rb └── manifests └── init.pp
Question 3: Will there be a way to confine which facts are synchronized to what hosts for compatibility reasons? Several suggestions were made and discussed at length.
- Sync all facts to all clients and fail silently if a fact could not be evaluated
- Have a folder structure based on kernel type that would sync facts to hosts with kernels matching the directory name
- Have an optional “.confine” file for each fact that uses s-exrpessions to define a list of conditions that would have to be met for the fact to be synchronized. The conditions would be based on other already existing facts
- Take a simplified approach to number 3 and have the confine only evaluate equality of values for existing facts. So “osfamily: RedHat” would be allowed, but no regex or && or || operators.
- Adjust Facter to not execute files with extensions [exe, com, bat] on unix systems (Currently these are the only extensions executed on Windows). Sync all facts to all systems. Cross platform compatibilty is up to the programmer of the fact to fail silently if need be by returning nil or perform different operations depending on the OS it is being run on.
The discussion concluded that 1 was too passive, 2-4 were too complex, so 5 was the best option.
The full details of the conversation can be found here: https://groups.google.com/forum/#!topic/puppet-dev/jKgqWO0y4H0
#14 Updated by Anonymous over 2 years ago
- Status changed from Accepted to Merged - Pending Release
- Target version set to 3.4.0
There were several different efforts around getting this to work. The initial functionality was merged into master in 19d28e1. After a few small fixes made once it started running through the entire test suite it got to some more exploratory testing and had another issue uncovered: the PMT stripped the execute permissions making bundling external fact scripts useless. This was fixed in merge e84ddb3.