Environment settings

[Gustavo Niemeyer]

William,

I get that we're under some pressure right now to finish this on time,
but while reviewing the couple of branches to introduce the
environment-wide settings, it feels like we're going into a bad
direction without proper evaluation, and it feels like it's just a
matter of organizing properly rather than a significant change. Let me
try to write down the problem as it'll help both of us understand it
better.

We have two branches in review right now, and one of them with some
review points that should be looked at no matter what:

https://code.launchpad.net/~fwereade/juju/use-ubuntu-series/+merge/76233
https://code.launchpad.net/~fwereade/juju/rearrange-settings-nodes/+merge/76463

With the two branches merged, we'll have two settings nodes in
zookeeper: /environment and /settings

Here are some facts about these nodes:

- /environment takes the configuration from the environment (good)
- /settings also takes the configuration for the environment as well (bad)
- /environment initializes post bootstrap from
~/.ensemble/environment.yaml (good)
- /environment is blindly replaced on every use afterwards (bad)
- /settings/debug-log is also necessary at the moment (bad)
- /settings is supposed to be modifiable via a subcommand (good)

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.
2) Introduce the default-series option in environments.yaml and /environment

For 12.04+:

3) Remove the auto-updating feature from environment.yaml
4) Move debug-log into the environment.yaml domain
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

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.

How does that sound?

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

-- I never filed a patent.