On Fri, Jun 6, 2014 at 4:39 PM, David Britton <david.brit...@canonical.com> wrote:
> As a user of juju swtich/juju env, I'd be sad to see it's very basic and > straightforward operation go. For instance, I can run: > > $(juju env) > > at any time in a shell and know for certain what environment I'm targeting > (and know immediately). It unwinds the mess that is env variable, default > yaml env, switch env. That is useful like 'hostname' or 'whoami' are > useful -- they may have limited functionality, but they do that job well. > Strongly agree: it's just that the output of that command, and the input into switch, is going to have to be from among the set of local aliases for particular connections that you know about. If you're mostly using environments from an environments.yaml, you can just use the default alias (ie the env-name in the yaml) and everything will work: that's what you do today. But when someone else starts an environment with the same internal name as one of yours, and shares access to it, you'll need to pick a name that doesn't collide with the aliases you already know. To restate your point, I think: you want to be able to keep seeing and reading simple names for the contexts you have available to work in. Do the following use cases express your needs (even if you weren't hitherto aware that you were specifically manipulating environment *connections*)? "As a user, I want to be able to refer to particular environment connections by short simple names" "As a user, I want to be able to see what environment connections I have available" "As a user, I want to be able to see what environment connection is currently active" "As a user, I want to be able to quickly activate a given environment connection" "As a user, I want to be able to see the details (env uuid, env name, state-servers, etc) of my environment connections" Cheers William > Just a thought. > > > > On Fri, Jun 6, 2014 at 3:34 AM, roger peppe <rogpe...@gmail.com> wrote: > >> On 5 June 2014 23:16, Tim Penhey <tim.pen...@canonical.com> wrote: >> > On 06/06/14 09:55, Jesse Meek wrote: >> >> I have a branch proposed that displays extra environment information >> >> when the --format flag is used with switch e.g: >> >> >> >> $ juju switch local --format yaml >> >> environ-name: local >> >> previous-environ-name: ec2 >> >> state-servers: >> >> - example.com >> >> - kremvax.ru >> >> username: joe >> >> >> >> There is some debate over this. Roger has summarised the key issues >> well >> >> in his review comment: >> >> >> >> "I think this is a bit odd. In every other command AFAIK, choosing a >> >> format does not affect the actual information displayed, just the >> format >> >> that it's printed in. >> >> >> >> Why are we printing all this info with the "switch" command anyway? >> >> Personally I'd think that a new command was warranted here, perhaps >> >> "juju current", or "juju show" or "juju info"." >> > >> > I was going to comment on the pull request, but since it has been >> > brought to the list, I will do it here and now. >> > >> > This change has grown and grown, and become somewhat of a moving target. >> > >> > The original request was: >> > "output the user for the environment when switching" >> > >> > I take some of the blame for this by not splitting the command up when I >> > initially wrote it. >> > >> > 'switch' has an alias of 'env' and I always ended up using >> > juju env >> > to see what my current environment was, and >> > juju switch >> > to change it. This alone should have told me that I should have changed >> > it, but I didn't. >> > >> > The core reason that the information is different at this stage is that >> > we don't want to break any existing clients, but we do want to lay the >> > foundations for changing the output on the next release. >> > >> > The idea that the output from the CLI may be being used and parsed by >> > scripts. This was one of the key reasons to add the formatting options. >> > >> >> My first implementation used a --env-info flag, but through review this >> >> was deemed to be not user friendly. I think the UX needs some >> discussion. >> >> >> >> 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 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: >> >> juju switch <environment-name> >> >> switches to the environment with the given name. >> >> juju switch >> >> prints the name of the current environment. >> >> juju switch --list >> >> prints all possible environment names that can be switched to. >> >> Then the entire "currency" of the switch command is environment >> names. Then you don't have to use juju info to find out what things >> you can pass to juju switch, and there's very little overlap >> between switch ad info. In other words, I think the switch command we have >> currently is just about right. >> >> > 4) juju env alias gets a deprecation warning (I'm sure we can work out >> > when a command is called through the alias), and next version we switch >> > the alias to be of 'info' not 'switch' >> >> +1 (except the last bit - I don't really think it's a particularly useful >> alias) >> >> > 5) add a juju info command that outputs: >> > * environment name >> > * uuid - if we have it >> > * api end points >> > * CACert - if we have it >> >> +1 on all of these. >> >> FWIW, we *should* always have the UUID and CACert. >> >> > * status - [running, stopped, and soon maybe suspended] >> >> I'm not sure about this. If this is supposed to be the current status >> of the environment, I'm -1 on it. I think this command should >> be about printing local info only - it can tell you what we >> know locally, but can work fast and independently of network >> or environment status. >> >> > * username >> > - supports json, yaml, and defaults to 'smart' >> >> +1 (but "smart" is such a rubbish name for a format :-)) >> >> > - juju info becomes an environment command, so you can say >> > juju info -e other-env >> > - fields default to [environment-name, status, username] >> > - all fields can be shown by using --all >> >> > 6) juju info --list will output the list of environments in either yaml >> > or json (or smart) >> >> Or perhaps just leave that to the juju switch command. >> >> cheers, >> rog. >> >> -- >> Juju-dev mailing list >> Juju-dev@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju-dev >> > > > > -- > David Britton <david.brit...@canonical.com> > > -- > Juju-dev mailing list > Juju-dev@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
