On Wed, Oct 28, 2009 at 11:28 AM, Luke Kanies <[email protected]> wrote: > > 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?
The facts look at local configuration on the client such as the debconf datastore or a property list. > Are your facts > just simple strings, or are they making complicated calculations based > on something on the client? It's not particularly complicated. It works out whether it's a Mac, Linux or Solaris box. It works out whether it's a desktop, laptop or server It works out whether the owner of the machine has decided to configure this machine to use unstable or testing. > > 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 > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
