On Tue, Oct 27, 2009 at 10:03 PM, Luke Kanies <[email protected]> wrote: > > On Oct 27, 2009, at 4:58 PM, Nigel Kersten wrote: > >> >> 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. > > Can you explain this in more detail? Do you move the entire machine > into testing temporarily, and then when it works move it back into > stable, do you have a pool of machines that slowly migrate to stable, > or what? I can see how you'd want to change it sometimes, but with > the above arrows, I see two transitions at most, since they're one-way.
So generally we work like this. The people responsible for a given platform will live on the relevant unstable environment. The people responsible for first/second level support of a platform will generally live on the relevant testing environment. The rest of the fleet generally lives on stable. Other teams may have one of their group of servers live on a testing environment, whereas the rest live in a stable environment. > >> 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. > > Can you explain this more? Well if the environment is determined by a fact, and you have all your facts distributed as plugins in environments... you have an issue with bootstrapping and getting the fact onto the client in the first place. The same would hold for any other facts that were used to compose an environment. > >> 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? > > Nope. :) :( I'll try again after coffee if this hasn't helped :) > >>> 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 >> >> > > > > -- > Basic research is what I am doing when I don't know what I am doing. > --Wernher von Braun > --------------------------------------------------------------------- > 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 -~----------~----~----~----~------~----~------~--~---
