On Oct 28, 2009, at 7:35 AM, Nigel Kersten wrote: > > 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.
But how/why do hosts flip between environments? That's the part I don't understand. How is it dynamic? >>> 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. That I see. If you're just downloading facts from the server to set the environment, though, how is that fundamentally different from the server owning what environment the client belongs to? Are your facts just simple strings, or are they making complicated calculations based on something on the client? Someone just proposed a good solution on the ticket: Telling the server what the client thinks its environment should be, and giving the server the ability to override it either way. So the server is always authoritative, but it can choose to let the client decide. That seems like the best overall approach, but it still leaves unsolved the overall complexity. -- While one person hesitates because he feels inferior, the other is busy making mistakes and becoming superior. -- Henry C. Link --------------------------------------------------------------------- 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 [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 -~----------~----~----~----~------~----~------~--~---
