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 <[email protected]> wrote: > On 27 May 2014 07:55, John Meinel <[email protected]> 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. >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
