+1
On Thu, Jun 5, 2014 at 6:16 PM, Tim Penhey <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
