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. 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. I wanted to check with the CI guys to see if it is going to break your infrastructure. I thought you started doing stuff like copying to a temp dir and rewriting information there (for the manual provider, etc). So maybe it is already sorted out. This patch may be a little while before landing, since ideally we won't change an API like Login without doing a version bump, but the infrastructure to do versioning isn't quite ready to land. John =:->
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
