Add a better 'upgrade' UX ansible-galaxy

[apollo13]

Proposal: Simplification of galaxy installation workflows

Author: Florian Apolloner @apollo13

Date: 2020-07-01

• Status: New
• Proposal type: core design

Motivation

With the introduction of collections and the split in ansible 2.10 collections are probably becoming more and more coming. Yet the workflow with ansible-galaxy seems to be bolted on and leaves a bit to be desired.

Problems

ansible-galaxy currently does not allow updates of roles that are already installed. The following error is shown after updating requirements.yml to a new version of a collection:

ERROR! Cannot meet requirement ericsysmin.system:1.0.0 as it is already installed at version '0.0.8'. Use --force to overwrite

This is suboptimal for multiple reasons:

• ansible-galaxy is probably the only package manager doing that. dnf/yum/apt/etc ask if you want to update and pip for instance will simply install the updated (or downgraded) version. Please note that the pip behaviour does make sense to me. After all the user showed intent when executing ansible-galaxy install -r requirements.yml.
• It is already hard enough to tell people to execute ansible-galaxy install every time they update a playbook from git etc (one could add that as post-checkout hooks). Telling them to execute it with --force every time makes it a somewhat useless flag.
• While the error raised is better than the warning for roles (after all ansible-galaxy did not do what it was asked to do), I think the UX of that is horrible.

Solution Proposal

I recommend automatically updating collections/roles to the requested version and or using a question Do you want to update X->Z Y/N like other package managers with a -y/--yes/--asume-yes flag to automatically do so.

[abadger]

• There is already a --force flag. Any prompting should obey that (so no need for a separate -y)
• In case people want separation between upgrade and install, I think UX should probably differentiate that via a separate, non-prompting flag.... It could be a command install vs upgrade or it could be a separate flag to install install --upgrade.
• IIRC, roles are not versioned so there's been resistance in the past to having upgrade apply to roles because there's no concept of what version is older or newer... only different. Restricting this to proposal to collections-only would solve that issue.

\CC @shertel @samdoran (since we talked about this just last week).

[webknjaz]

I think that it's reasonable to expect ansible-galaxy install to perform the upgrade automatically whenever the requested version is not satisfied by the currently installed collections. OTOH if the deps are already there, it should just skip installing the dependency. I think that having ansible-galaxy install --upgrade (or -U) is a good idea too.

[abadger]

These are related but not necessarily needed for this discussion (they're how @shertel, @samdoran, and I ended up talking about the upgrade case:

• ansible-galaxy collection list vs site-packages ansible#70147 (comment)
• Collection list site packages ansible#70173

[sivel]

FWIW we already have a feature request for --upgrade: ansible/ansible#65699

[apollo13]

There is already a --force flag. Any prompting should obey that (so no need for a separate -y)

I disagree with that, as outlined by @geerlingguy in ansible/ansible#65699 (comment) I also think that --force is a terrible UX and goes against everything people are used to (ie most prominently rm -f etc).

I also don't think that --upgrade alone is a solution, it makes sense in this situation:

➜  ~ ansible-galaxy collection install ericsysmin.system
Process install dependency map
Starting collection install process
Skipping 'ericsysmin.system' as it is already installed

Ie if the collection is already installed and I install it again nothing changes. In this case adding --upgrade would update the existing collection to the latest version.

--upgrade imo makes no sense when I explicitly specify a version:

➜  ~ ansible-galaxy collection install ericsysmin.system:1.0.0

In this case I want it to update, I explicitly told it which version I want. Also --upgrade doesn't solve the situation when you want to downgrade a collection.

In the end I think a somewhat natural behaviour would be the following:

• If no version is specified, install the collection if missing, otherwise tell the user it is already installed
• If no version is specified and the collection is installed, allow upgrades via install --update/--upgrade
• If a version is specified take that as clear user intent and upgrade/downgrade as needed

I think this matches mostly matches the behaviour of pip.

As @abadger mentioned, roles are somewhat of a different beast, so I'll happily leave them out of the discussion and accept the existing behaviour there. I do not think that adding a new command ala upgrade itself would solve the issue either. We still would need to handle the situation ansible-galaxy install namespace.coll:version which should imo install or upgrade -- at which point the upgrade command becomes rather useless.

I'll try to make it to the meetings next week if you think the discussion has some merit. If you shoot it down by then I'll also accept that, but it would be great if we could collect more points on the ticket here since IRC is somewhat hard for longer texts ;)

[willthames]

See also #7 - I don't think the landscape has really improved in the four years since I wrote that one.

[abadger]

There is already a --force flag. Any prompting should obey that (so no need for a separate -y)

I disagree with that, as outlined by @geerlingguy in ansible/ansible#65699 (comment) I also think that --force is a terrible UX and goes against everything people are used to (ie most prominently rm -f etc).

I agree with the UX you propose so I probably stated this bullet point badly. What I want to avoid is having to specify --force and -y on the same commandline. To me, --force and -y are so similar in meaning as to be redundant. (I also want some commands to require -y to achieve an unattended install and other commands to require --force to do that. Because they seem to have the same meaning, that seems like it would lead to perpetual confusion as to which was required on this command line).

In the end I think a somewhat natural behaviour would be the following:

* If no version is specified, install the collection if missing, otherwise tell the user it is already installed

* If no version is specified and the collection is installed, allow upgrades via `install --update/--upgrade`

* If a version is specified take that as **clear user intent** and upgrade/downgrade as needed

+1. No need for prompting; everything is unambiguous with this UX.

[webknjaz]

--upgrade imo makes no sense when I explicitly specify a version:

It does make sense. For example, in pip, it'd know to upgrade the dependencies instead of not touching them (even though the requested installable is satisfied).

[C0rn3j]

I have read comments in a few threads and I have not been able to understand why the install command has different behavior for collections and roles.

You can upgrade collections just fine, but roles have to be force reinstalled every time to upgrade, which is not an ideal for obvious reasons.

[bcoca]

collections have a defined and required versioning specification, roles do not, so it is possible to reliably handle collections but not roles.