Some Juju CLI usability thoughts before we close 2.0

[John Meinel]

On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth <ian.booth at canonical.com> wrote:

> A few things have been irking me with some aspects of Juju's CLI. Here's a
> few
> thoughts from a user perspective (well, me as user, YMMV).
>
> The following pain points mainly revolve around commands that operate on a
> controller rather than a model.
>
> eg
>
> $ juju login [-c controllername] fred
> $ juju logout [-c controllername]
>

I would agree with 'juju login' as it really seems you have to supply the
controller, especially since we explicitly disallow logging into the same
controller twice. The only case is 'juju logout && juju login'. Or the 'I
have to refresh my macaroon' but in that case couldn't we just do "juju
login" with no args at all?



>
> I really think the -c arg is not that natural here.
>
> $ juju login controllername fred
> $ juju logout controllername
>
> seem a lot more natural and also explicit, because....
> I know without args, the "current" controller will be used...
> but it's not in your face what that is without running list-controllers
> first,
> and so it's too easy to logout of the wrong controller accidentally. Having
> positional args solves that.
>

I'm fine with an optional positional arg and "juju logout" removes you from
the current controller. As it isn't destructive (you can always login
again), as long as the command lets you know *what* you just logged out of,
you can undo your mistake. Vs "destroy-controller" which is significantly
more permanent when it finishes.



>
> The same would then apply to other controller commands, like eg add-model
>
> $ juju add-model mycontroller mymodel
>
> One thing that might be an issue for people is if they only have one
> controller,
> then
>
> $ juju logout
> or
> $ juju add-model
>
> would just work and requiring a controller name is more typing.
>

I disagree on 'juju add-model', as I think we have a very good concept of
"current context" and adding another model to your current controller is a
natural event.


>
> But 2 points there:
> 1. as we move forward, people reasonably have more than one controller on
> the go
> at any time, and being explicit about what controller you are wanting to
> use is
> a good thing
> 2. in the one controller case, we could simply make the controller name
> optional
> so juju logout just works
>
> We already use a positional arg for destroy-controller - it just seems
> natural
> to do it everywhere for all controller commands.
>

destroy-controller was always a special case because it is an unrecoverable
operation. Almost everything else you can use current context and if it was
a mistake you can easily recover.


>
> Anyways, I'd like to see what others think, mine is just the perspective
> of one
> user. I'd be happy to do a snap and put it out there to get feedback.
>
> --
>
> Another issue - I would really, really like a "juju whoami" command. We
> used to
> use juju switch-user without args for that, but now it's gone.
>
> When you are staring at a command prompt and you know you have several
> controllers and different logins active, I really want to just go:
>
> $ juju whoami
> Currently active as fred at controller2


I'd say you'd want what your current user, controller and model is, as that
is the current 'context' for commands.


>


> Just to get a quick reminder of what controller I am operating on and who
> I am
> logged in as on the controller.  I know we have a way of doing that via
> list
> controllers, but if there's a few, or even if not, you still need to scan
> your
> eyes down a table and look for the one wit the * to see the current one
> and then
> scan across and get see the user etc. It's all a lot harder than just a
> whoami
> command IMO.
>
> --
>
> We will need a juju shares command to show who has access to a controller,
> now
> that we have controller permissions login, addmodel, superuser.
>
> For models, we support:
>
> $ juju shares -m model
> $ juju shares (for the default model)
>
> What do we want for controller shares?
>
> $ juju shares-controller  ?
>

It would certainly at least be "controller-shares" (and
list-controller-shares) not "shares-controller".


>
> which would support positional arg
>
> $ juju shares-controller mycontroller   ?
>

Again, current context is perfectly ok here. We use current context for all
model commands (juju status doesn't require you to specify the model each
time). And arguably you're switching controller far less often than you
would be switching models.

I wonder if we could roll controller shares just into the same command.


> --
>
> On the subject of shares, the shares command shows all users with access
> to a
> model (or soon a controller as per above). That's great for admins to see
> who
> they are sharing their stuff with. What I'd like as a user is a command to
> tell
> me what level of access I have to various controllers and models. I'd like
> this
> in list-controllers and list-models.
>
> $ juju list-controllers
>
> CONTROLLER       MODEL    USER         CLOUD/REGION   ACCESS
> fredcontroller*  foo      fred at local                  addmodel
> ian              default  admin at local  lxd/localhost  superuser
>

FWIW, we're really trying to get rid of the @local syntax, as you're either
a local user or a user in the external IDM, but we only support a single
external, so we don't have to distinguish between them.


>
> $ juju list-models
>
> MODEL  OWNER       STATUS     ACCESS  LAST CONNECTION
> foo*   fred at local  available  write   5 minutes ago
>
> The above would make it much easier to see if I could add a model or
> deploy an
> application etc. And I don't get to see who else has access like with juju
> shares, just my own access levels. Thoughts?
>
>
"juju models" and "juju controllers" does indeed seem a good place to list
your username and your access level.

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20160811/d209678b/attachment.html>