On Oct 15, 2008, at 7:12 PM, David Lutterkort wrote:
>
> On Wed, 2008-10-15 at 22:13 +0100, Paul Nasrat wrote:
>>>> For domain name resolution in particular, I see no reason to have
>>>> all
>>>> these independent resolutions with no confines, since we do want
>>>> them to
>>>> be executed in a fixed order. I provide a patch in #1654 that
>>>> merges
>>>> all
>>>> these resolutions into one.
>
> [ This was first bit was from Luke; for some reason, your reply didn't
> make it to me, though I did remove you from my killfile a while
> ago ;) ]
>
>>> I'm sure everyone wants them executed in a specific order, I'm just
>>> not sure everyone wants them in the same order.
>
> Agreed; but making the order of resolutions configurable seems like
> quite a bit of work; for starters, you'd need a way to reference
> existing resolutions and define an order for them after the fact -
> this
> assumes that facter would ship with a bunch of resolutions, and users
> would need to be able to rearrange existing resolutions.
Right -- and then you'd need some kind of configuration file that
provided customized orders for each resolution.
Adding (and really, requiring) unique names for each resolution is
pretty simple, but it's a pretty big departure.
There are enough API changes I want that I'm tempted to make a new
interface entirely, rather than trying to provide backward
compatibility through the existing interface. I.e., requiring that
all of the custom facts out there be upgraded seems too much; instead,
only support custom orders with facts defined through the new interface.
Another thing I really want to fix is the 'setcode' stuff -- it's
pretty ugly, and should be possible to be much easier.
>
>> If it's well documented behaviour and obvious when people are writing
>> new facts, then I'm not sure that having a hard rule (eg specific
>> beats generic) would be that unpalatable. I'd not want to change that
>> in a minor release, but for 2.0 or for 1.6 maybe.
>
> Definitely, though it's not entirely easy to come up with a good rule,
> since you need to define an ordering for resolutions in the same file
> and for the order in which facts are loaded from files.
>
> Would definitely be easiest to just stick an explicit 'order' or so
> field into each resolution, e.g.
>
> Facter.add(:domain) do
> order 200
> setcode do
> ...
> end
> end
We're moving to this kind of syntax as much as possible:
Facter.add(:domain, :order => 200) { ... }
And I'd probably prefer 'priority' rather than 'order', but...
>
> FWIW, the issue that I saw with domainname being used before other
> domain resolutions was that (on a RHEL5 system with facter-1.5.2 from
> RPM)
> facter domain
> and
> RUBYLIB=/usr/lib/ruby/site_ruby/1.8 facter domain
> gave different answers, one of which happened to be correct, though
> obtained in the wrong way.
>
> What triggered the difference is that in the second form the default
> facts are loaded twice (since /usr/lib/ruby/site_ruby/1.8/facter
> appears
> on $: twice) - adding those additional facts seems to have changed the
> order of the domain resolutions with no confines.
Yeah, this is a strange problem -- on the one hand, we want long-
running processes to reload code, but on the other hand, we only want
a given resolution to show up once.
If each resolution had a unique name, it'd be much easier, because you
could trivially replace the existing resolutions.
--
The great thing about television is that if something important
happens anywhere in the world, day or night, you can always change
the channel. -- From "Taxi"
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
