On Tue, Oct 27, 2009 at 4:32 PM, Luke Kanies <[email protected]> wrote:
>
> On Oct 27, 2009, at 3:09 PM, Markus Roberts wrote:
>
>> So one thought, what if there were one (and only one) place to get
>> the environment but the value could optionally be an expression/
>> lambda/special token of some sort that would pull the value from
>> some other (specified) location?
>>
>> That gets rid of the whole issue of what-trumps-what, or at least
>> sidelines it; we may still want some sources (e.g. the command line)
>> to take precedence but we don't have to sort a long list of sources
>> based on a whole slew of use cases.
>>
>> * Does that sound reasonable?
>> * Where should the one-true-place be?
>> * Is the command line (for interactive use) the only thing that
>> should best it?
>> * Are there any use cases that this wouldn't handle?
>
> IMO, that's not really a great idea, because you then have to have
> quite a bit of ugly code that knows how to interpret that token, and
> you've really just punted + invented a new templating system.
>
> Given the current state of affairs in Puppet:
>
> We know that external nodes needs to be able to set it, which means we
> need the client to be able to query its environment from the server.
> That's a chunk of work we can be sure we'll have to do.
>
> We also know that the client needs to be able override values, both
> permanently and temporarily, which, at the least, means it needs to be
> tunable whether we pull that env info from the server.
>
> My first question is, is there a design flaw somewhere else that's
> forcing either of these requirements?
>
> For instance, I know Volcane has mentioned that the reason he
> overrides environments on clients is because it's the only way he can
> force ordering. Maybe to fix the environment mess we have to fix this
> problem? Are there other reasons people override the environment on
> the client?
>
> Nigel, I know you want this client-side override; what do you use it
> for?
So we have too many clients and too much flux in our client base to be
able to centrally define this.
We have environments like:
hardy_desktop_{unstable, testing, stable}
hardy_laptop_{unstable, testing, stable}
mac_laptop_{unstable, testing, stable}
and we follow the unstable -> testing -> stable release process. We
need individual machines to be able to flip between
unstable/testing/stable versions of their environment without having
to centrally define them.
If the server was capable of setting the client environment based upon
a composite of other fact values, then that would essentially give me
the same functionality and I wouldn't have a need for this anymore,
but I'm unsure how the chicken/egg problem would get resolved.
Currently we work around the problem of initial distribution of the
fact by running the clients with a --factsync and a tag that is pretty
much a noop, so the client gets facts from the default location, then
the environment fact is available on the "real" puppet run that
happens next.
This is on 0.24.x of course. I haven't yet worked out how I'll deal
with this with 0.25 clients when I turn off factsync and move all of
this to plugins in modules.
Does that make things clearer?
>
> I think that, organizationally, it makes a lot more sense for the
> central location to own which environment a given host is in. I'd
> like to see us provide the functionality necessary to completely
> remote the need for client-side overrides, but I'm not yet convinced
> that's possible.
>
> --
> You wake me up early in the morning to tell me I am right? Please
> wait until I am wrong. -- Johann von Neumann
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
> >
>
--
nigel
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
