Support controller: instead of -c controller for commands

[Mark Shuttleworth]

When we are referring to a controller we can use a name: construct (i.e. the controller name followed immediately by a colon). For example.

  $ juju models ms-gcp-eu:
  ...

Currently we seem to look for "-c controller" which feels fine but pedantic. The general structure for a command which can take a controller and/or model should be that controller: or controller:model or controller:/path/to/model suffice.

I think this should apply to (at least):

  status
  models
  users
  ...

[Richard Harding (rharding)]

The issue here is that some commands take arguments afterwards which could be confusing and lead to some inconsistency. status takes an optional argument for the application/unit. juju resources requires the application name, and so the -m is used there to allow a user to say juju resources -m controller:model percona-cluster.

The -c or -m lets us make any command accept that argument regardless of how it works.

It does suck that some commands take the -c because they're controller specific (models, users) but others take the -m because they're intended to be model specific (status, machines, etc) yet take the controller as well. In a way you really just want to be able to --target controller, model, controller:model on any command.

What are your thoughts on keeping the flag so that we can keep things out of trouble with the specifics of the command run, but trying to change up the flag used to be consistent across all commands?

[Mark Shuttleworth (sabdfl)]

I think this is a design process, and if we accept complexity as an
unchangeable given then we will always end up with something even more
complex than we have today. I would say, we're Juju every day in a
multi-controller multi-model way, and we should design the whole
experience to be fantastic with that as an everyday reality. If we say
the goal is to make it feel natural and comfortable all day long with
many controllers hosting many models, then we'll get to the right place.

So, let's design what we WANT then implement it. It's useful to know why
we got into the current position, but it's not useful to treat that as
an unchangeable constant.

Mark

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 5 years, so we're marking it Expired. If you believe this is incorrect, please update the status.