$ juju switch --format

roger peppe rogpeppe at gmail.com
Fri Jun 6 09:34:17 UTC 2014


On 5 June 2014 23:16, Tim Penhey <tim.penhey at 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.



More information about the Juju-dev mailing list