Story #5890: [Epic] The ansible-pulp installer needs to handle multiple versions of Pulp
As a user, I can download & run a version of the ansible installer that a specific version of Pulp 3
Currently users are encouraged to get the latest ansible-pulp roles via git cloning. Later on, Ansible Galaxy.
The only stable tag ever done was 3.0.0rc1. Presumably we will create them for 3.0.0 and later.
However, consider the following scenario (hypothetical release dates):
1. They download the roles (either method) on Apr 1. They are versioned as 3.0.3 and install pulp 3.0.3
2. They run them against their test env and it works.
3. Pulp 3.1.0 & ansible-pulp 3.1.0 are released on Apr 15.
4. They run the 3.0.3 roles against their prod env on May 1.
5. The 3.0.3 roles try to install pulp 3.1.0 from pip, but fails due to the lack of new logic.
It would make sense to have a variable for the pulp version to install, that defaults to the same version as the roles, but can be overriden (but doing so is discouraged.)
Plugin versions would also be an issue. Let's discuss how this can be handled.
Also, I am not sure if there is an existing task for publishing the roles (other than pulp_rpm_prerequisites) to Ansible Galaxy (pulp project on it.):
#8 Updated by email@example.com 9 months ago
I am also not sure if we have a task on publishing to Galaxy, but we should. That would cover the releasing part.
bmbouter: I intend to add that as a subtask.
We still want users to follow our example top-level playbooks (example-use/playbook.yml) though. I'm thinking of embedding them in the metadata/README that Galaxy will display.
#9 Updated by firstname.lastname@example.org 9 months ago
This makes sense to me. +1 to starting to branch, version, and release the installer.
Also, our current thinking is that we would use one continuous branch for the installer, and use variables (or auto-detection) to decide whether to install, and to apply the 3.0.x specific config logic, the 3.1.x specific config logic, etc.
There would still be a need for some versioning though. Since the 3.0.x specific config logic and the 3.1.x specific config logic will change over time. You wouldn't want users to experience a bug or inability to start due to them running say the 3.0.0 installer when they try to install 3.0.9.
Please register to edit this issue