$ juju switch --format

[William Reade]

On Fri, Jun 6, 2014 at 11:34 AM, roger peppe <rogpeppe at gmail.com> wrote:

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

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.

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 at 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.

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.
>

The switch command we have currently is imo pretty close, *but* environment
names are inadequate. If it's to do its job right, it needs to understand
that every environment switch is also a user switch.

>  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.
>

Non-bootstrapped environments may have neither, and they might not have
state servers either. And we should always show the UUID if we have it, but
the CACert is verbose geek-only information that will bury the stuff people
actually care about. Hide those behind a flag please.

>     * 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.
>

I think the intent is that it shows what it can infer based on available
state. I don't think it's expected to try to connect to the environment.

>     * 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
>

This is maybe the heart of the confusion: an "environment command" is
already, inescapably, a "user-environment-pair command". `juju *anything*
-e "scare-quotes-env-name" ...` is fundamentally flawed in at least two
ways, because (1) env-names are not globally unique, and at least one
person will inevitably have access to multiple envs with the same name;
and, as previously stated (2) even if env names were globally unique, they
still wouldn't be enough information to uniquely specify an intended
connection to an environment.

But the good news is that it already functions perfectly well as a user/env
command. It takes *jenv* names already, and those names are literally local
aliases for user/env pairs. (It'll fall back to environment names in
environments.yaml, true, but even those have an implicit "admin" user.)

The challenge lies in cleanly expressing this reality to users of the
command. But if we persist in the fiction that switch uses env names, and
we only supply the auxiliary information (that people really do need if
they want to make sense of switch itself) in a separate command, we're not
crafting a pleasant experience.

>  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.
>

Indeed. The dividing line between the proposed commands is not clear.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140606/a10adb5f/attachment.html>