Project

Profile

Help

Story #5618

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

Added by mdepaulo@redhat.com 11 months ago. Updated 5 months ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

46%

Estimated time:
(Total: 0:00 h)
Platform Release:
Groomed:
No
Sprint Candidate:
Yes
Tags:
Sprint:
Quarter:

Description

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.
https://github.com/pulp/ansible-pulp/releases

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.):
https://galaxy.ansible.com/pulp


Subtasks

Task #6072: Make ansible-pulp's versions correspond to a specific version of pulpcoreCLOSED - CURRENTRELEASEmdepaulo@redhat.com

Actions
Task #6073: Adapt pulp_installer CI for ansible-pulp branches ASSIGNEDmdepaulo@redhat.com

Actions
Task #6535: Separate the pulp_installer CI jobs: release vs sourceCLOSED - CURRENTRELEASEmdepaulo@redhat.com

Actions
Task #6547: pulp_installer: Add variables for molecule prepare.yml to clone the branchesASSIGNEDmdepaulo@redhat.com

Actions
Task #6548: pulp_installer CI: prereq roles to use variables for what branches they test againstPOSTmdepaulo@redhat.com

Actions
Task #6549: pulp_installer CI: prereq roles to clone the desired branch / release of pulp_installerNEW

Actions
Task #6550: pulp_installer CI: Modify tag jobs to only run release testsNEW

Actions
Task #6551: pulp_installer: Implement support for PyPI pre-releasesNEW

Actions
Task #6552: pulp_installer CI: Create docs or scripts to help maintain which branches & tests get usedNEW

Actions
Task #6553: Add "Required PR" support for pulp_installer to prereq rolesCLOSED - CURRENTRELEASE

Actions
Task #6557: Add "Required PR" support for pulpcore & plugins to pulp_installerASSIGNEDmdepaulo@redhat.com

Actions
RPM Support - Task #6108: Start doing versioned releases of pulp_rpm_prerequisites on Ansible GalaxyNEWmdepaulo@redhat.com

Actions
RPM Support - Task #6109: Document downloading the pulp_rpm_prerequisites exact version in pulp_rpm docsNEWmdepaulo@redhat.com

Actions

History

#1 Updated by mdepaulo@redhat.com 11 months ago

  • Description updated (diff)

#2 Updated by mdepaulo@redhat.com 11 months ago

  • Description updated (diff)

#3 Updated by mdepaulo@redhat.com 11 months ago

  • Description updated (diff)

#4 Updated by mdepaulo@redhat.com 11 months ago

  • Tags Pulp 3 installer added

#5 Updated by fao89 10 months ago

  • Tags CI/CD added

#6 Updated by mdepaulo@redhat.com 9 months ago

  • Tags deleted (CI/CD, Pulp 3 installer)

#7 Updated by bmbouter 9 months ago

This makes sense to me. +1 to starting to branch, version, and release the installer.

I am also not sure if we have a task on publishing to Galaxy, but we should. That would cover the releasing part.

#8 Updated by mdepaulo@redhat.com 9 months ago

bmbouter wrote:

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 mdepaulo@redhat.com 9 months ago

bmbouter wrote:

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.

#10 Updated by mdepaulo@redhat.com 9 months ago

  • Parent task set to #5890

#11 Updated by mdepaulo@redhat.com 9 months ago

  • Subject changed from As a user, I can download & run a version of the ansible installer that corresponds to a specific version of Pulp 3 to As a user, I can download & run a version of the ansible installer that supports specific branches of Pulp 3

#12 Updated by mdepaulo@redhat.com 8 months ago

  • Subject changed from As a user, I can download & run a version of the ansible installer that supports specific branches of Pulp 3 to As a user, I can download & run a version of the ansible installer that a specific version (or branches) of Pulp 3

#13 Updated by mdepaulo@redhat.com 8 months ago

  • Subject changed from As a user, I can download & run a version of the ansible installer that a specific version (or branches) of Pulp 3 to As a user, I can download & run a version of the ansible installer that a specific version of Pulp 3

#14 Updated by mdepaulo@redhat.com 8 months ago

Note: This task description was modified some to switch away from multiple supported branches to one specific version of pulpcore.

The issue/scenario is still addressed though.

Please register to edit this issue

Also available in: Atom PDF