On 11/08/16 17:03, John Meinel wrote: > On Thu, Aug 11, 2016 at 9:30 AM, Ian Booth <ian.bo...@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. >
Fair point. > > > > > 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@controller2 > > > I'd say you'd want what your current user, controller and model is, as that > is the current 'context' for commands. > Agreed, adding model would be necessary. > > > > > > > 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". > Bah, had a dyslexic moment. Yes, controller-shares > > > > > 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. > I think that could work, a single juju shares command shows the shares for the current context (controller and model) in a tabular display with a [CONTROLLER] and a [MODEL] section. And yaml/json would work nicely too. > > > -- > > > > 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@local addmodel > > ian default admin@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. > Yeah, I just cut and pasted from a running Juju beta14. Clearly there's a bug there to clean up that output. I thought we had such a bug raised already, I'll have to go try and find it. > > > > > $ juju list-models > > > > MODEL OWNER STATUS ACCESS LAST CONNECTION > > foo* fred@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 > =:-> > -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
