Environment settings

[William Reade]

On Wed, 2011-09-21 at 16:30 -0300, Gustavo Niemeyer wrote:
> So, with that in mind, I propose a simplification of what we're doing
> for 11.10, and a follow up plan for the next releases.
> 
> For 11.10:
> 
> 1) Drop /settings. The file is redundant with /environment.

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

> 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 ;).

> 
> 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).

> 5) Add a new environ command to control the remote one. E.g.:
> 
> juju environ --show
> juju environ --set debug-log=true
> juju environ --set default-series=oneiric
> juju environ --add-ssh-keys

Very nice.

> 
> 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).

(Hmm: maybe the distinction is between "provider" settings and
"environment" settings..?)

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?

> 
> How does that sound?
> 

11.10 goals make perfect sense, consider me on them.

Let me know what you think about the rest...