This has been a great discussion, thanks everyone for participating. I
think we're at a point where we've come to an agreement so here's the
summary I'd like to post to the redmine ticket.
----
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/ directory at the base of the
module. So an example tree would be:
mymodule
├── facts
│ └── 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.
1. Sync all facts to all clients and fail silently if a fact could not be
evaluated
2. Have a folder structure based on kernel type that would sync facts to
hosts with kernels matching the directory name
3. 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
4. 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.
5. 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
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
