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
