On 9 June 2014 21:57, Tim Penhey <tim.pen...@canonical.com> wrote:
> OK, this has gone WAY beyond any reasonable work for this work item.
Total agreement. I intended my remarks as more a future-looking
"where are we aiming for?" than "we should do this now".
For current work, I think that:
a) the juju switch command is just fine as it is now.
b) we could use a juju info (or similarly named) command
that shows information on the currently selected environment,
including user name, UUID, etc.
Both of these should be forwardly compatible with all
my suggestions.
> 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.
Let's do this. It interacts with some of the stuff I am working on,
hence my interest here.
cheers,
rog.
>
> Tim
>
> On 09/06/14 22:07, roger peppe wrote:
>> On 6 June 2014 14:20, William Reade <william.re...@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 <rogpe...@gmail.com> wrote:
>>>>
>>>> On 5 June 2014 23:16, Tim Penhey <tim.pen...@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@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@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.
>>
>
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
