Environment settings

[Gustavo Niemeyer]

> I presume you mean "revert /global_settings to how it was before" (i.e.
> containing just debug-log).

Yeah, not touching it now.

>> 2) Introduce the default-series option in environments.yaml and /environment
>
> Sounds good to me; the environment replacement was what led me to avoid
> using it in the first place, because it meant we'd be forced to use
> environments.yaml, and we couldn't explicitly set it at bootstrap time
> or overwrite it later (as specced). environments.yaml does give us all
> the functionality we wanted, just not in quite the way we originally
> hoped ;).

Right.. the auto-updating wasn't an intended feature. It was just
solving the bootstrap problem we have. We can't have different
administrators fighting over the content of the remote environment by
syncing up everyone's local copy, so I suggest we just keep things for
now, and in the future we implement manual updating and disable the
auto one.

>> For 12.04+:
>>
>> 3) Remove the auto-updating feature from environment.yaml
>> 4) Move debug-log into the environment.yaml domain
>
> Not quite sure about this: even if we're not auto-updating /environment,
> we're still going to be waking every agent for *any* change (rather than
> just any debug-log change... and attempting to avoid this was what led
> to the /settings work in the first place).

I agree we may have to look at this again when we're supporting a
massive number of computers that could cause a herd effect, but really
the changes to global settings should be manual and extremely rare in
proportion, and by the time the herd effect becomes an issue in that
scenario the debug-log feature we have today is entirely unsuitable
anyway.

>> There's still a minor conceptual conflict we should solve in terms of
>> the local environment.yaml file differing from the settings of the
>> real running environment. We can warn the user about these, or maybe
>> move certain settings under a different global option name within the
>> file (e.g. "bootstrap:..."). Either way, we have some time on how to
>> solve that part, and it doesn't invalidate the rest of the plan I
>> think.
>
> I think there's an important distinction somewhere here, but I'm having
> a bit of difficulty putting my finger on it; it's something like the
> difference between "access" settings (URLs, usernames, passwords) and
> "behaviour" settings (default series, instance type, debug log, *maybe*
> authorised SSH keys, ...).
>
> Settings of the first kind match the existing /environment pretty well,
> but the second kind is a bit trickier; they're either things that might
> change at runtime (debug-log), or that are more to do with the "what"
> than the "where" of your deployment (consider stacks: they're the
> settings that you want to persist in the stack, so that you can deploy
> the same stuff on EC2 as on Orchestra (and in exactly the same way, as
> much as possible), rather than the ones that simply control access to a
> particular provider).

I lost you here.

> So, nebulous as the foregoing may be, I'd like us to think a bit more
> about it before we commit to treating all environment settings the same.
> Does anyone else understand/share my concerns, or should I try to
> express them differently?

Yeah, expressing them differently might be helpful.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I never filed a patent.