OK, this has gone WAY beyond any reasonable work for this work item. I agree that we may well want to change how we store things on disk, but I won't be doing that for this work. If we are going to do this, and I can see some benefits of doing it, it needs to be spec'ed out as an independent piece of work.
Tim On 09/06/14 22:07, roger peppe wrote: > On 6 June 2014 14:20, William Reade <[email protected]> wrote: > > Thanks for these very useful and constructive remarks. I now > understand better where the original proposal was coming from. > >> On Fri, Jun 6, 2014 at 11:34 AM, roger peppe <[email protected]> wrote: >>> >>> On 5 June 2014 23:16, Tim Penhey <[email protected]> wrote: >>>>> Addressing the concerns, can we not: >>>>> >>>>> $ juju switch [env] >>>>> $ juju info >>>>> # display env info of env user just switched into >>>> >>>> OK, here is my proposal, which I hope addresses all the concerns and >>>> gives us a way forwards. >>> >>> This looks like a great direction, thanks. >>> >>>> 1) juju switch with no args becomes deprecated (replaced by juju info) >>>> and will be removed one release following, continues to work as before >>>> 2) juju switch --list becomes deprecated (replaced by juju info) >>>> 3) juju switch <new-env> --format=[json,yaml] will output new >>>> information, but just environment name, old env name and username >> >> >> I'm not sure this is a win. At the moment, switch is actually pretty >> cohesive: it's the command that deals with setting the user/environment that >> will apply to future commands; it provides a way to get information about >> the current user/environment; and it lists the available choices for the >> active form. >> >> This proposal splits away a seemingly arbitrary subset of the >> user/environment information -- parts of which are actually necessary to >> distinguish between environments in only-mildly-pathological cases (eg, >> `"tim" in "prod"` is not enough information to unambiguously specify where >> you've actually switched to) -- and puts it behind a separate command; I'm >> not convinced that your experience of a clear separation between "switch" >> and "env" is a general one. > > It's true that "tim" in "prod" isn't enough information to unambiguously > specifiy where you've actually switched to, but I wonder if that > actually matters. If we treat environment names as local aliases > for global entities, then each user can be under total control > of their local names, and thus can know what environment > a given name refers to because they chose it - it's their > chosen nickname for the environment, so from a *user's* point > of view, it could be considered unambiguous. > > Part of my issue with putting user information into switch was > that I was looking at our current state of affairs, where > an environment name unambiguously specifies an > environment and a user-creds pair. > >> The main thrust of my suggestion was that we (1) accept that switch, when >> switching, needs to output more information when switching so that you can >> tell where you've switched to; and (2) make sure we integrate the change >> fully, such that switch's other modes also output what the user actually >> needs to be aware of, while preserving but deprecating the original >> behaviour for one release. Part of doing this right is implementing the >> --format flag for the result data; and the shared implementation for the >> --format flag lets you specify a default that lets you mangle a given object >> into a list of bytes however you desire. >> >> By implementing an output formatter that takes the common in-memory result >> format and expresses the original output format of that data -- flawed and >> incomplete though that format may be -- we get to use a single mechanism >> across the board and perfectly encapsulate the old output format such that >> removing or changing it becomes literally trivial. >> >>> I don't see why the username creeps in here. As I understand it, >>> switch is just about switching environments. If we keep it that way, >>> I think it makes coherent sense as a command if we have these >>> possible usages of it: >> >> >> "environment" is an inadequate concept. You're almost always *some user in* >> some environment. We can't hide it, we have to expose it, but it's >> potentially confusing so we need to do it tastefully. > > Yes. > >>> juju switch <environment-name> >>> >>> switches to the environment with the given name. >> >> >> You have two jenvs for the same environment named "prod", as users "admin" >> and "roger" (roger has fewer permissions). (Or, equivalently, your identity >> on your state server gives you access to those users in those environments.) >> Similarly, in the same way, you have access to another environment, created >> by me and also named "prod", in which you also have the username "roger". >> What does `juju switch prod` do? Even with, say, `juju switch roger@prod`, >> there's scope for ambiguity and hence bad experiences. >> >> I think that you have to allow aliases for user/environment pairs, and have >> `juju switch` use those aliases to control both user-switching and >> environment-switching. If you can come up with an alternative that cleanly >> separates the concepts I will be most interested. > > How about something like this? > > We split the current .jenv file into two - one part holding the CA cert > and the API endpoint (and potentially the bootstrap config too). > We also add a level of indirection between the environment name and the > UUID. > > We store the following data (where [x] represents zero or more > x, (a, b, c) represents a tuple holding a and b and c, a? represents > an optional a, and a->b represents > a one-many mapping from a to b) > > ( > EnvName -> UUID, > UUID -> ( > (UUID, CACert, [APIEndpoint], BootstrapConfig?) > UserName -> UserCredentials, > ) > ) > > In this notation, our current situation looks like this: > > EnvName -> (UUID, CACert, [APIEndpoint], UserName, UserCredentials) > > In a file system, the proposed setup might look like this: > > $JUJU_HOME/environments/ > <EnvName>.uuid (holds UUID of environment) > <UUID>.jenv (holds UUID, CACert, [APIEndpoint]) > <UUID>/ > <UserName>.creds (holds UserName, UserCredentials) > > Given that structure, a local environment name implies > an environment and a set of user names that are valid > in that environment. We can still keep exactly the existing behaviour for > switch when there is only one user name (because in that > case the user is unambiguously specified), but we now have some additional > possibilities: > > - when there are no user names (for instance, a .jenv file has > been imported), a user name and password could be prompted for > and then saved. Alternatively, this might be better done with > an explicit "login" command. > > - when there are several user names, a variant of the switch > command could be used to change the current user for a given > environment, say "juju switch -u <username>". Alternatively, > we could come up with a syntax for specifying the user > name and environment name in a single word (e.g. tim@prod), > though we'd want to be careful not to limit the range > of possible user names there (I could imagine that an email address > might make a good user name, for example). > > The level of indirection between environment name and UUID > makes it simple and reliable to have a shared repository of > environment endpoint information without the need to decide > on a shared environment name space. > > In the hope that this might be useful, > > cheers, > rog. > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
