Story #5890
Updated by mdepaulo@redhat.com almost 5 years ago
This is an overall Epic for the following needs for our ansible installer:
1. Performing upgrades of Pulp (e.g., 3.0 -> 3.1)
2. Performing updates of Pulp (e.g., 3.0.0 -> 3.0.1)
3. Providing a way for users to obtain the version, or branch, of Pulp they want. Whether this is branches of the installer, or variables within the installer.
4. Handling the case where a user may run an outdated installer to install the current version of Pulp, and thus either the install failing or pulp failing at runtime because of it.
5. Allowing users to not update or upgrade Pulp with the installer; so that it is safe for them to re-run it without modifying the state of a correctly configured system. (idempotency / managing drift). This applies to pulpcore, but should apply to plugins as well.
Some pip limitations (without a third party cool like pip-compile) that were pointed out:
1. pip will let you upgrade a dependency (pulpcore), without checking whether it will break dependent packages (plugins.)
2. Indirect deps conflicts are not handled. (For example, if pulpcore depends on libjuicer>=1.0<2.0, and pulp_oranges depends on libjuicer=>1.0, libjuicer 2.0 might get installed and break pulpcore.)
I would like to propose a design for this overall Epic (in terms of variables for ansible-pulp, releases on ansible galaxy) based on what pip (the ansible pip module) can do, etc. I would like to put a propose design on the ML.
.