[wishlist] move -m parameter to the top level
Bug #2002686 reported by
Peter De Sousa
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical Juju |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
Hello
When using juju there is a parameter supported by most sub commands with few exceptions, resulting in a cumbersome juju SUBCOMMAND -m MY_MODEL_VALUE for each and every command, when switching between two models at the same time.
If the juju -m argument was shifted up one level user alias are enabled, for example:
alias juju="juju -m MY_MODEL_VALUE"
juju SUBCOMMAND now is implictly run on the correct model, or expicit user alias can be used;
alias juju-myk8s="juju -m MY_K8S_MODEL"
juju-myk8s status
Thanks!
Peter
Revision history for this message
| Ian Booth (wallyworld) wrote | #1 |
| Changed in juju: | |
| milestone: | none → 3.2-beta1 |
| status: | New → Triaged |
| importance: | Undecided → Wishlist |
Revision history for this message
| Peter De Sousa (pjds) wrote | #2 |
| Changed in juju: | |
| milestone: | 3.2-beta1 → 3.2-backlog |
| tags: | added: cli model parameter |
| Changed in juju: | |
| milestone: | 3.2-backlog → none |
To post a comment you must log in.
Interesting idea. It's likely a little interesting to implement due to how things are wired up using a generic CLI upstream package - the upstream CLI package which parses args etc has no knowledge of what a juju model is. Plus not all juju commands operate on a model (some work with a controller for example) and so handling when -m is valid as an arg to "juju" would need thought. It could be that options can be marked as "subcommand" options and simply passed through to the subcommand by the top level.
I'll assign to a milestone and we can take a closer look...