$ juju switch --format

[Tim Penhey]

OK, this has gone WAY beyond any reasonable work for this work item.

I agree that we may well want to change how we store things on disk, but
I won't be doing that for this work.  If we are going to do this, and I
can see some benefits of doing it, it needs to be spec'ed out as an
independent piece of work.

Tim

On 09/06/14 22:07, roger peppe wrote:
> 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.
>