[JUJU-796] WIP Remove most alias commands

[jack-w-shaw]

With the exception of relate and status which require more thought

Here is a full list of the command changes from juju:

• Drop list-actions in favour of actions
• Drop list-operations in favour of operations
• Drop upgrade-charm in favour of refresh (Is this sensible?)
• Drop remove-consumed-application in favour of remove-saas
• Drop resolve in favour of resolved (Is this sensible?)
• Drop list-disabled-commands in favour of disabled-commands
• Drop list-cached-images in favour of cached-images
• Drop set-default-credential in favour of default-credential
• Drop set-default-region in favour of default-region
• Drop list-clouds in favour of clouds
• Drop list-credentials in favour of credentials
• Drop list-regions in favour of regions
• Drop show-credentials in favour of show-credential (is this sensible?)
• Drop update-credentials in favour of update-credential (is this sensible?)
• Drop help-tool and hook-tools in favour of hook-tool (is this sensible? A few of references to help-tool in codebase)
• Drop list-ssh-keys in favour of ssh-keys
• Drop sync-tools in favour of sync-agent-binaries (is this sensible?)
• Drop upgrade-juju in favour of upgrade-model
• Drop list-controllers in favour of controllers
• Drop list-models in favour of models
• Drop list-offers in favour of offers
• Drop list-firewall-rules in favour of firewall-rules
• Drop list-machines in favour of machines
• Drop model-default in favour of model-defaults (is this sensible?)
• Drop list-commits in favour of commits (wtf??)
• Drop list-charm-resources in favour of charm-resources
• Drop list-resources in favour of resources
• Drop attach in favour of attach-resource (is this sensible?)
• Drop list-agreements in favour of agreements
• Drop list-plans in favour of plans
• Drop list-wallets in favour of wallets
• Drop list-secrets in favour of secrets
• Drop list-spaces in favour of spaces
• Drop debug-hook in favour of debug-hooks (is this sensible?)
• Drop list-storage in favour of storage
• Drop list-storage-pools in favour of storage-pools
• Drop list-subnets in favour of subnets
• Drop list-users in favour of users
• Drop list-payloads in favour of payloads
• Drop show-status in favour of status

And from juju-metadata

• Drop generate-tools in favour of generate-agents (is this sensible?)
• Drop validate-tools in favour of validate-agents (is this sensible?)

Checklist

• ~[ ] Requires a pylibjuju change~
• [x] Added integration tests for the PR
• ~[ ] Added or updated doc.go related to packages changed~
• [ ] Comments answer the question of why design decisions were made

QA steps

make static-analysis
go test github.com/juju/juju/cmd/juju/...
go test github.com/juju/juju/cmd/plugins/juju-metadata
go test github.com/juju/juju/payload/status

$ juju help commands | grep Alias
relate                     Alias for 'add-relation'.
status                     Alias for 'show-status'.

$ juju list-users
ERROR juju: "list-users" is not a juju command. See "juju --help".

Documentation changes

Probably does require a documentation change or two

Bug reference

N/A

[jameinel]

wallets and plans should just be removed rather than worrying about list-* variants. I don't remember any discussion about removing list-* variants. We can certainly discuss it.

I don't like hook-tool because it is the 'help about hook tools' and it is neither plural nor help. Though the singular also exists for the juju hook-tool unit-get (juju hook-tools unit-get is awkward, but so is juju hook-tool listing all hook tools). I think we should have more discussion here. (I'm personally fine with getting rid of juju help-tool )

Hm. maybe I should go one by one, with a caveat that I don't believe we concretely decided to get rid of all list-* variants, but those would be taken as a group (either we should get rid of all of them, or leave them all).

• Drop upgrade-charm in favour of refresh (Is this sensible?) seems reasonable

• Drop remove-consumed-application in favour of remove-saas fine

• Drop resolve in favour of resolved (Is this sensible?) fine

• Drop set-default-credential in favour of default-credential This one I'm not sure about. juju default-credential aws myawscred is concrete, but not quite as clear as juju set-default-credential aws myawscred. More discussion I think.

• Drop set-default-region in favour of default-region Similar to set-default-credential

• Drop show-credentials in favour of show-credential (is this sensible?) Personally I think the singular and plural forms are helpful to users here.

• Drop update-credentials in favour of update-credential (is this sensible?) same

• Drop help-tool and hook-tools in favour of hook-tool (is this sensible? A few of references to help-tool in codebase) I think this needs a bit of design discussion.

• Drop sync-tools in favour of sync-agent-binaries (is this sensible?) Yes.

• Drop upgrade-juju in favour of upgrade-model Yes

• Drop model-default in favour of model-defaults (is this sensible?) It feels awkward when setting one default juju model-defaults aws foo=bar, I think the singular is still useful here.

• Drop list-commits in favour of commits (wtf??) Ask Joe, but this should be a hidden command anyway (I thought it was only enaled with a feature flag)

• Drop attach in favour of attach-resource (is this sensible?) We also have attach-storage so we shouldn't reserve the single word, so I think it is good to drop.

• Drop list-plans in favour of plans

• Drop list-wallets in favour of wallets wallets and plans should be dropped completely.

• Drop debug-hook in favour of debug-hooks (is this sensible?) I think it helps users if they can juju debug-hook mongodb install.

• Drop show-status in favour of status Seems ok. I know we had designs around show being more common (show-unit, etc), but I don't know anyone that uses show-status.

And from juju-metadata

Drop generate-tools in favour of generate-agents (is this sensible?)
Drop validate-tools in favour of validate-agents (is this sensible?)

Those really should be agent-binaries vs agents, though it does make them a bit unweildy (though they are very infrequently used).

[hloeung]

Can't keep up with all the command changes. Any chance we can ensure backwards compatibility? We have tools written around as well as documentation and playbooks.

[sajoupa]

* Drop resolve in favour of resolved (Is this sensible?)
  fine

I remember a lot of users being confused by "resolved" back when it was the only option. Going back would be quite unpleasant.

[jnsgruk]

Can't keep up with all the command changes. Any chance we can ensure backwards compatibility? We have tools written around as well as documentation and playbooks.

Unfortunately we've been carrying a lot of these for a really long time, and having multiple ways to achieve the same thing breaks any kind of consistency in the command line and makes it difficult for beginners (or not!) to figure out the "right patterns". Note that these changes will land in Juju 3, a major release - which is about the only time we get to make such changes.

* Drop resolve in favour of resolved (Is this sensible?)
  fine

I remember a lot of users being confused by "resolved" back when it was the only option. Going back would be quite unpleasant.

I actually agree here. Most of the commands we have contain a verb/noun combo. resolved vs resolve seems like a strange trade off - I personally feel like juju resolve foo makes more sense.

[jack-w-shaw]

Revisiting this for the rc release of 3.0.

We've decided to keep both resolve and resolved, since there was some disagreement. The plan is to re-design this in future

We've also decided to keep list-* aliases, as we don't feel the term on it's on juju models, juju controllers is very clear in intention to beginners, particularly given the practice of [binary] [noun] [verb] practised by kubectl and the like

[jack-w-shaw]

/build

[jack-w-shaw]

/merge