Possible CI affecting change

[roger peppe]

On 27 May 2014 07:55, John Meinel <john at arbash-meinel.com> wrote:
> I just proposed this branch:
> http://code.launchpad.net/~jameinel/juju-core/login-returns-env-tag/+merge/221021
>
> This will make it so that we end up caching the environment UUID into our
> ENV.jenv file, and passing it up when we try to connect, and having it
> validated to match the running environment.
>
> I believe CI uses some infrastructure to avoid having Juju automatically
> generate a bunch of the fields in .jenv files (CACert and control-bucket
> come to mind). Environment UUID is going to be one of those things that gets
> generated during bootstrap (it always has been uniquely generated, we just
> never actually tracked it before).
>
> Some of this is moving us toward multi-environment state servers, where we
> can tell what environment you want access to from your Login request. And
> some of this is a general desire that we've had that when you run a command
> you know that you're actually connecting to the environment you thought you
> were. And the official descriptor for an environment is its internal UUID.

To reiterate a little of what I mentioned online:

I think the latter is a good thing to do, and this change seems reasonable
to do that. For the former, I think that a better approach might be to
encode the environment UUID into the URL used to attach to the API.
That can be entirely orthogonal to all the current API handling, and
easily gets us environment-specific access to other URLs served by
the API, such as local charm uploading and logs without any other
change to the protocols.

Does that sound reasonable as an eventual aim? It means that we'd be
explicitly treating the UUID in the login request as *verification* info,
not for *selection* of environments, but since there's only one environment
currently, you won't be able to tell :-)

> However, this would mean that if you bootstrap, and have a .jenv file, then
> someone out-of-band destroys that environment and bootstraps it again,
> you'll now refuse to operate with this new environment that no longer
> matches the old one.

FWIW, that's the case in general anyway because entries like
control-bucket are generated afresh when bootstrapping.
So it would be worth sorting this out anyway if it is a problem.

  cheers,
    rog.