$ juju switch --format

[roger peppe]

On 6 June 2014 14:20, William Reade <william.reade at canonical.com> wrote:

Thanks for these very useful and constructive remarks. I now
understand better where the original proposal was coming from.

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

It's true that "tim" in "prod" isn't enough information to unambiguously
specifiy where you've actually switched to, but I wonder if that
actually matters. If we treat environment names as local aliases
for global entities, then each user can be under total control
of their local names, and thus can know what environment
a given name refers to because they chose it - it's their
chosen nickname for the environment, so from a *user's* point
of view, it could be considered unambiguous.

Part of my issue with putting user information into switch was
that I was looking at our current state of affairs, where
an environment name unambiguously specifies an
environment and a user-creds pair.

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

Yes.

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

How about something like this?

We split the current .jenv file into two - one part holding the CA cert
and the API endpoint (and potentially the bootstrap config too).
We also add a level of indirection between the environment name and the
UUID.

We store the following data (where [x] represents zero or more
x, (a, b, c) represents a tuple holding a and b and c, a? represents
an optional a, and a->b represents
a one-many mapping from a to b)

(
    EnvName -> UUID,
    UUID -> (
        (UUID, CACert, [APIEndpoint], BootstrapConfig?)
        UserName -> UserCredentials,
    )
)

In this notation, our current situation looks like this:

EnvName -> (UUID, CACert, [APIEndpoint], UserName, UserCredentials)

In a file system, the proposed setup might look like this:

$JUJU_HOME/environments/
    <EnvName>.uuid (holds UUID of environment)
    <UUID>.jenv (holds UUID, CACert, [APIEndpoint])
    <UUID>/
         <UserName>.creds (holds UserName, UserCredentials)

Given that structure, a local environment name implies
an environment and a set of user names that are valid
in that environment. We can still keep exactly the existing behaviour for
switch when there is only one user name (because in that
case the user is unambiguously specified), but we now have some additional
possibilities:

- when there are no user names (for instance, a .jenv file has
been imported), a user name and password could be prompted for
and then saved. Alternatively, this might be better done with
an explicit "login" command.

- when there are several user names, a variant of the switch
command could be used to change the current user for a given
environment, say "juju switch -u <username>". Alternatively,
we could come up with a syntax for specifying the user
name and environment name in a single word (e.g. tim at prod),
though we'd want to be careful not to limit the range
of possible user names there (I could imagine that an email address
might make a good user name, for example).

The level of indirection between environment name and UUID
makes it simple and reliable to have a shared repository of
environment endpoint information without the need to decide
on a shared environment name space.

In the hope that this might be useful,

  cheers,
    rog.