Environment settings

William Reade william.reade at canonical.com
Thu Sep 22 21:18:15 UTC 2011


On Thu, 2011-09-22 at 16:17 -0300, Gustavo Niemeyer wrote:
> >> 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.

Baldly: settings which control access to an environment are
qualitatively different from settings that control the behaviour of an
environment; and if we aren't careful to differentiate between them in
some way, we risk damaging the portability-across-providers story.

For example, if I don't have my AWS keys accessible when I clone a
deployment from EC2 to Orchestra, that's good. If I'm suddenly running a
different default OS when I do the same, that's bad. So: some settings
are about the provider, and some are about the deployment, and we should
probably have some idea which is which (and how we should be handling
them in different scenarios).

Better? :)

(Incidentally: I think the fact that we're duplicating settings like
placement and default-series in the different provider schemas is an
indication that we've drawn the lines slightly wrong, and I think it's
related to this discussion.)




More information about the Juju mailing list