On 11/08/16 17:46, Ian Booth wrote: > > 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. >
And as Rick pointed out, this mirrors charm whoami nicely too. So we get that level of consistency across our Juju 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". >> > > Bah, had a dyslexic moment. Yes, controller-shares > Rick brought up a great suggestion - we should just add the access level to list-users. This then fits in with the same approach below for list controllers and list models. >> >>> >>> 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
