Support controller: instead of -c controller for commands

Bug #1600523 reported by Mark Shuttleworth on 2016-07-09
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

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):


Changed in juju-core:
status: New → Triaged
importance: Undecided → Medium
tags: added: 2.0 usability
Richard Harding (rharding) wrote :

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?

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.


Changed in juju-core:
milestone: none → 2.0.0
affects: juju-core → juju
Changed in juju:
milestone: 2.0.0 → none
milestone: none → 2.0.0
Curtis Hovey (sinzui) on 2016-10-06
Changed in juju:
milestone: 2.0.0 → 2.0.1
Curtis Hovey (sinzui) on 2016-10-28
Changed in juju:
milestone: 2.0.1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers