On Oct 26, 2009, at 12:16 PM, R.I.Pienaar wrote:

>
> hello,
>
> ----- "Luke Kanies" <[email protected]> wrote:
>
>> On Oct 26, 2009, at 11:40 AM, R.I.Pienaar wrote:
>>
>>>
>>> hello,
>>>
>>> ----- "Markus Roberts" <[email protected]> wrote:
>>>
>>>> * Sites that need this functionality can set up a starting
>>>> environment
>>>> for nodes that only pushes the configuration file, and the
>>>> configuration file can be a template filled in with the
>> appropriate
>>>> external_node parameters. This will require an extra cycle for new
>>>> nodes and for existing nodes when their environment changes at
>> such
>>>> sites, but would not require any code changes or have any impact
>> on
>>>> sites that don't need it.
>>>
>>> I'd say this should be the last resort, I've seen several places
>>> that changes a machines environment fairly often, during maintenance
>>
>>> periods for example.
>>>
>>> Forcing the environment change to only happen after another run
>>> would be very bad for them.
>>>
>>>> * Change puppet to request the node information from the server
>>>> before
>>>> anything else (e.g. before plugins). This would have a small
>> overhead
>>>> for all puppet runs and necessitate a moderately small code
>> change.
>>>
>>> nice.
>>>
>>>> * Change the default environment on the client to a special "ask
>> the
>>>> server" environment. Clients that specified an environment in
>> their
>>>> configuration or on the command line would use that environment.
>>>> Clients that did not specify an environment would request it from
>> the
>>>> server, imposing a small overhead only for machines that needed
>> it.
>>>> This would require a somewhat larger code change.
>>>
>>> Even nicer.  I assume we can then specify on the server the default
>>> environment that all unconfigured nodes would end up in? This would
>>> be very nice indeed.
>>
>> Yes.  The "somewhat larger" code change part, though, is both more
>> code and decent bit more complexity - having values vary based on
>> client vs. server is annoyingly complicated.
>
>
> But it isn't really different behavior from what we had in 0.24.x so  
> I think there's an expectation.  I can see how it's a pain code wise  
> though.

I'ts more of a pain data-flow-wise than code, I think.  In talking it  
over with Markus today it became clear how, um, unclear the whole "who  
owns the environment" thing really is.

0.24 was relatively straightforward in this area if you only did  
simple things, but it was complicated enough that if you did anything  
weird than I think it quickly turned into craziness.

>>> Keeping in mind that it is also very desirable to be able to set the
>>> environment via a fact.
>>
>> Hmm.  Using facts complicates things even further, because it's
>> another way for the client to specify the environment.  Why do you
>> want to be able to do that?
>
> machines know where they are and in what environment they are, it  
> seems a logical extension.  I've never seen this documented as  
> something that should work, but always been glad it does :)
>
> I think Nigel use this method extensively as well, and it does work  
> with 0.25.1rc2

Who should win between facts and external nodes?

>> The next question becomes, do we need to do this for 0.25.1?  I would
>> tend to say no, we ship 0.25.1 nowish (because it's ready), and only
>> do this for either a 0.25.2 if we produce one, or rowlf.
>
> I think 0.25.1 should get out there quick as we can really, and if  
> we go for the above there'll be a lot of code changes, not the kind  
> of thing to do at rc2 stage imho.


Ok.

-- 
Always behave like a duck - keep calm and unruffled on the surface but
paddle like the devil underneath. -- Jacob Braude
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to