Environment settings

[Kapil Thangavelu]

Excerpts from Gustavo Niemeyer's message of Wed Sep 21 12:30:49 -0700 2011:
> 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?
> 

Sounds good to me! I was hoping the series handling could be unified with our 
existing provider config, which will need multi-user handling anyways.

So currently the environment is composed almost entirely of provisioning agent 
options and with the security work, this node becomes unreadable to any other 
agent types. The debug-log setting is separate and will need to continue 
to be so because it needs to be readable by every agent. So regardless of the 
cli exposed, the internal implementation will need to be a different node.

this cli syntax is interesting, i'm wondering if we should also adopt it
for service config (ensemble set).. which currently doesn't have any options to 
show the schema (possible options) or current settings.. for oneiric +1.

cheers,

Kapil