Possible CI affecting change

[John Meinel]

They are/were hard-coding CACert and control-bucket (because they can). I
believe they tried dropping control-bucket and then ended up getting locked
out of their Canonistack account (not necessarily more than random
correlation, but I believe it spooked off Curtis from making that change
again).

John
=:->


On Tue, May 27, 2014 at 3:36 PM, roger peppe <rogpeppe at gmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140527/0c288ec2/attachment.html>