On Mar 9, 2010, at 10:56 PM, Paul Nasrat wrote:
On 10 March 2010 06:41, Luke Kanies <[email protected]> wrote:
On Mar 9, 2010, at 10:35 PM, Paul Nasrat wrote:
On 10 March 2010 03:56, Nigel Kersten <[email protected]> wrote:
On Tue, Mar 9, 2010 at 5:52 PM, Luke Kanies
<[email protected]>
wrote:
On Mar 9, 2010, at 5:09 AM, Michael DeHaan wrote:
{
"facts": {
"network": {
"interface": "eth0",
"ip": "192.168.0.1",
"netmask": "255.255.255.0",
},
"disk": {
"name": "sda1",
"size": "1000",
}
},
}
Yep, that's pretty much what I was proposing. I'm a big fan of
structured stdin/stdout interfaces for quick extensibiility (and
JSON).
We could start by doing something that supports non-
datastructured
facts now, and add datastructures later.
For now, it could just assert in the code that the type of each
hash
key was a string or int.
I concur on the basic plan.
I'd add that having some plain data, like /etc/facter.d/foo,
wouldn't be
all
bad, either, so you could just statically declare facts.
++
I reckon something like:
/etc/facter/facter.conf (main config file)
/var/lib/facter/data.d/ (plain text files containing fact values)
/var/lib/facter/plugins.d/ (foreign language executables
returning fact
values)
The natural location for all these things differs across
platforms, so
it should be added to the install.rb script to make them
configurable... http://projects.reductivelabs.com/issues/3361
I'd also love to move the default search path logic not to be
$LOAD_PATH.collect { |d| File.join(d, "facter") }, so we can have a
sensible (ie not everything under util/) hierachy for facter's core
functionality. But that's probably a breaking change, but we can
safely add say a configurable location for native facts in parallel
with config, key/value fact files and executable fact files.
Can you explain in more detail what you mean here?
Currently facter consists of basically
facter.rb
facter/[facts].rb
facter/util/actual_facter_code/helpers
The classes responsible for actually doing things in facter -
resolution, loading, etc are buried under util. It's not a major thing
but I think it's cleaner to split it the other way (make the facts in
a special place, and the code under facter), having
facter/util/config.rb for handling the config seems wrong .
So eg we could eventually try move to having
facter/facts (for ruby facts)
FACTERLIB
The reason I didn't do this is because now the few -- us developers --
have to deal with this subdirectory, while the many -- the many people
writing facts -- can just act like it's not there and put things
directly into facter/.
I know it makes our dev a bit less attractive, but it makes extensions
much easier. Do you really want to try to explain to everyone that
facts go into facter/facts? This is hard enough with providers --
people seem to almost always put them in puppet/providers/ rather than
puppet/providers/$type/.
I can also see us potentially wanting to think about how we deal with
fact hierachies potentially moving things into directories so that we
can split up or conditionalize/collapse the order of loading a bit. A
lot of facts have implicit dependencies on just one, or two core facts
for the purposes of confines. It
That I agree with.
It's not something I'm overly worried about for now, but if we're
changing the code related to ordering I'd like to be provide the
ability to configure the equivalent of FACTERLIB in the config, and
potentially override the behaviour to say *only look here*. That could
work around some of the issues in the past that have bitten us with
testing under Hudson when we change facter and have an earlier facter
installed on the system we pick up stuff from the system and you get
unexpected failures due to the interaction.
I agree, that would be nice.
OTOH, this is relatively easily solvable by just installing Puppet/
Facter in /opt or something on the Hudson hosts, so normal ruby won't
find them.
--
Getting caught is the mother of invention. --Robert Byrne
---------------------------------------------------------------------
Luke Kanies -|- http://reductivelabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups "Puppet
Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
