Facter design
Paul Nasrat
resolving facts based on namespace eg: ipaddress_eth1 ...
I had a quick look at the yaml output as I was thinking about what do
facts mean. Initially my eye was drawn to quoting discrepancies. Then
I started to think ok so if interfaces is a list, why is it not a
list and just rendered to_s in a sane way. Then I thought about things
like ipmess.py, the problem we have is the poor mapping to fact by
name vs where it's implemented. Looking at ohai, I quite liked the
encapsulation where it was present of say interfaces contain named
interfaces which have the relevant facts for the specific interface.
This got me thinking about the facter data model and loader resolution
model. I think we should actually start thinking about the having a
first class fact object rather than buried under util and looking for
the facts based upon FACTERLIB and the $LOAD_PATH of facter itself.
Paul
James Turnbull
Hash: SHA1
Agreed.
A tiered data model works a lot better for some (all?) facts.
Especially if you can traverse up and down the tier for key=value and
structured output.
I am happy with the first class fact object - Luke?
Regards
James Turnbull
- --
Author of:
* Pulling Strings with Puppet
(http://www.amazon.com/gp/product/1590599780/)
* Pro Nagios 2.0
(http://www.amazon.com/gp/product/1590596099/)
* Hardening Linux
(http://www.amazon.com/gp/product/1590594444/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJcocp9hTGvAxC30ARAvxbAKDUVVK7vzggN0RJ4vTjW9mzs1RHRQCgj9EJ
BzRQ1Vjax07Pro1aoo7kyp8=
=VLLX
-----END PGP SIGNATURE-----
Paul Nasrat
> Especially if you can traverse up and down the tier for key=value and
> structured output.
Yeah I sort of see the easy wins for not breaking stuff in having
either to_s methods and some way of key flattening to map to our
currently shallow structure of type_instance.
Paul
Luke Kanies
I'm a bit unclear on the differences between that and what we have,
but I'm certainly open to a redesign. Facter's design has essentially
not changed since the initial development 4 or so years ago, and given
how small and simple it is, it's pretty unlikely that the original
design is worth retaining.
I'm certainly all for getting as much insight as we can from ohai.
--
People are more violently opposed to fur than leather because it is
safer to harrass rich women than motorcycle gangs.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
Nigel Kersten
Something we've been meaning to have a look at is more related to how
Puppet works with Facter than standalone facter I guess.
A broken fact shouldn't break a Puppet run at all, and it is possible
to do this at the moment.
--
Nigel Kersten
Systems Administrator
Tech Lead - MacOps
Ohad Levy
Something we've been meaning to have a look at is more related to how
Puppet works with Facter than standalone facter I guess.
A broken fact shouldn't break a Puppet run at all, and it is possible
to do this at the moment.
Cheers,
Ohad
Nigel Kersten
That's the one. The only time we've had to manually sort things out on
puppet clients has been when we've accidentally pushed a broken fact
to clients.
This is made somewhat worse by it being difficult to have facts part
of the environment. We've set up a 'facts' module in each environment
that is where clients get their facts from, but on first run you end
up with a chicken or the egg problem where the server doesn't know
what environment the client has, and even if you supply the
environment on the command line, it's still ignored as far as the
initial factsync goes.
Luke Kanies
>
> On Tue, Jan 20, 2009 at 7:27 AM, Ohad Levy <ohad...@gmail.com> wrote:
>> O
>>>
>>> Something we've been meaning to have a look at is more related to
>>> how
>>> Puppet works with Facter than standalone facter I guess.
>>>
>>> A broken fact shouldn't break a Puppet run at all, and it is
>>> possible
>>> to do this at the moment.
>>
>>
>> I would agree with Nigel, I think he is referring to something like:
>> http://projects.reductivelabs.com/issues/show/1527
>
> That's the one. The only time we've had to manually sort things out on
> puppet clients has been when we've accidentally pushed a broken fact
> to clients.
Hmm, I think the only real way to fix this is to explicitly iterate
over all of the Facter facts, rather than using to_hash; that way
individual facts can fail without failing the whole process.
>
> This is made somewhat worse by it being difficult to have facts part
> of the environment. We've set up a 'facts' module in each environment
> that is where clients get their facts from, but on first run you end
> up with a chicken or the egg problem where the server doesn't know
> what environment the client has, and even if you supply the
> environment on the command line, it's still ignored as far as the
> initial factsync goes.
Really? Is that filed? It's certainly a bug, if so. I know the
environment stuff isn't as thorough as it needs to be; it's obviously
caught me a bit by surprise at how hard it is to get every little piece.
BTW, looks like the RailsMachine guys have been working on some
extensions to both Puppet and Facter[1], and I hope to see a post from
Jesse Newland soon describing these. The Facter stuff is currently a
thin wrapper around the existing code, so it's completely backward
compatible but makes it cleaner and easier to use.
1 - http://blog.railsmachine.com/articles/2009/01/16/moonshine-configuration-management-and-deployment/
--
There are no such things as applied sciences, only applications of
science. -- Louis Pasteur
Nigel Kersten
differently, but it hasn't worked out as well as we hoped.
Which behavior do you consider to be the bug? The fact that the server
doesn't take the environment into account until after the factsync
process?
>
> BTW, looks like the RailsMachine guys have been working on some
> extensions to both Puppet and Facter[1], and I hope to see a post from
> Jesse Newland soon describing these. The Facter stuff is currently a
> thin wrapper around the existing code, so it's completely backward
> compatible but makes it cleaner and easier to use.
>
> 1 - http://blog.railsmachine.com/articles/2009/01/16/moonshine-configuration-management-and-deployment/
>
> --
> There are no such things as applied sciences, only applications of
> science. -- Louis Pasteur
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
Luke Kanies
>
> On Wed, Jan 21, 2009 at 3:59 PM, Luke Kanies <lu...@madstop.com> wrote:
>>
>> On Jan 20, 2009, at 10:58 AM, Nigel Kersten wrote:
>>
>>>
>>> This is made somewhat worse by it being difficult to have facts part
>>> of the environment. We've set up a 'facts' module in each
>>> environment
>>> that is where clients get their facts from, but on first run you end
>>> up with a chicken or the egg problem where the server doesn't know
>>> what environment the client has, and even if you supply the
>>> environment on the command line, it's still ignored as far as the
>>> initial factsync goes.
>>
>>
>> Really? Is that filed? It's certainly a bug, if so. I know the
>> environment stuff isn't as thorough as it needs to be; it's obviously
>> caught me a bit by surprise at how hard it is to get every little
>> piece.
>
> I'll file it this week. We were attempting to work around it
> differently, but it hasn't worked out as well as we hoped.
>
> Which behavior do you consider to be the bug? The fact that the server
> doesn't take the environment into account until after the factsync
> process?
Yep.
--
Brand's Asymmetry:
The past can only be known, not changed. The future can only be
changed, not known.
Nigel Kersten
>> I'll file it this week. We were attempting to work around it
>> differently, but it hasn't worked out as well as we hoped.
>>
>> Which behavior do you consider to be the bug? The fact that the server
>> doesn't take the environment into account until after the factsync
>> process?
>
>
> Yep.
Done.
http://projects.reductivelabs.com/issues/show/1882
Let me know if that wasn't informative enough.