<div dir="ltr">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).<div>
<br></div><div>John</div><div>=:-></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 27, 2014 at 3:36 PM, roger peppe <span dir="ltr"><<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 27 May 2014 07:55, John Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<br>

> I just proposed this branch:<br>
> <a href="http://code.launchpad.net/~jameinel/juju-core/login-returns-env-tag/+merge/221021" target="_blank">http://code.launchpad.net/~jameinel/juju-core/login-returns-env-tag/+merge/221021</a><br>
><br>
> This will make it so that we end up caching the environment UUID into our<br>
> ENV.jenv file, and passing it up when we try to connect, and having it<br>
> validated to match the running environment.<br>
><br>
> I believe CI uses some infrastructure to avoid having Juju automatically<br>
> generate a bunch of the fields in .jenv files (CACert and control-bucket<br>
> come to mind). Environment UUID is going to be one of those things that gets<br>
> generated during bootstrap (it always has been uniquely generated, we just<br>
> never actually tracked it before).<br>
><br>
> Some of this is moving us toward multi-environment state servers, where we<br>
> can tell what environment you want access to from your Login request. And<br>
> some of this is a general desire that we've had that when you run a command<br>
> you know that you're actually connecting to the environment you thought you<br>
> were. And the official descriptor for an environment is its internal UUID.<br>
<br>
</div>To reiterate a little of what I mentioned online:<br>
<br>
I think the latter is a good thing to do, and this change seems reasonable<br>
to do that. For the former, I think that a better approach might be to<br>
encode the environment UUID into the URL used to attach to the API.<br>
That can be entirely orthogonal to all the current API handling, and<br>
easily gets us environment-specific access to other URLs served by<br>
the API, such as local charm uploading and logs without any other<br>
change to the protocols.<br>
<br>
Does that sound reasonable as an eventual aim? It means that we'd be<br>
explicitly treating the UUID in the login request as *verification* info,<br>
not for *selection* of environments, but since there's only one environment<br>
currently, you won't be able to tell :-)<br>
<div class=""><br>
> However, this would mean that if you bootstrap, and have a .jenv file, then<br>
> someone out-of-band destroys that environment and bootstraps it again,<br>
> you'll now refuse to operate with this new environment that no longer<br>
> matches the old one.<br>
<br>
</div>FWIW, that's the case in general anyway because entries like<br>
control-bucket are generated afresh when bootstrapping.<br>
So it would be worth sorting this out anyway if it is a problem.<br>
<br>
  cheers,<br>
    rog.<br>
</blockquote></div><br></div>