$ juju switch --format

[Nate Finch]

+1


On Thu, Jun 5, 2014 at 6:16 PM, 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.
>
>  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
>  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'
>  5) add a juju info command that outputs:
>     * environment name
>     * uuid - if we have it
>     * api end points
>     * CACert - if we have it
>     * status - [running, stopped, and soon maybe suspended]
>     * username
>    - supports json, yaml, and defaults to 'smart'
>    - 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)
>
> In all honesty, I should have done this originally.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140605/70eeb2ef/attachment.html>