Upgrade Pulp Container Version While Retaining Existing Container Artifacts

Development
#1

Description

We are planning to upgrade our Pulp container to a newer version. The current Pulp container hosts container artifacts (RPMs, Files, Images etc) that were previously synced using an older Pulp version (3.80.1).

Our objective is to upgrade Pulp container version without losing or re-syncing the existing container artifacts, ensuring that all previously synced artifacts remain available and usable after the upgrade.

Request

We would like guidance on the following:

  1. Recommended upgrade procedure for a single Pulp container running pulp repositories.
  2. Whether existing artifacts synced on an older Pulp version remain compatible after upgrading Pulp.
  3. Any migration steps required for container metadata, repositories, or artifacts during the upgrade.
  4. Whether there are known compatibility issues between different Pulp versions that could affect previously synced artifacts.
  5. Best practices to ensure zero data loss and minimal downtime during the upgrade.

Environment Details

  • Current Pulp Version: 3.80.1
  • Target Pulp Version: latest version of Pulp
  • Deployment Type: Single Pulp Container

Expected Outcome

  • Successful upgrade of the Pulp container to latest version
  • Existing container artifacts and repositories remain intact
  • Ability to continue serving and syncing artifacts without re-syncing existing content
#2

@Vrinda_Marwah Sorry for the delayed reply, but upgrading Pulp is really simple:

  1. Backup your /pgsql folder before upgrading. This is where all the PG data lives so, useful to have a backup in case you need to revert.
  2. Stop your running Pulp container, then boot up a new container with your desired new version. (The tags determine the version, e.g. pulp/pulp:3.105)
  3. The Pulp container will automatically run the migrations needed on startup and since your are running the single Pulp container, all the API, Content, and Task workers will be on the new version.

As for your questions:
2. Yes, existing artifacts remain compatible.
3. Migrations should be handled automatically. If they fail there will usually be an error message with what you need to do.
4. No, typically different versions will not affect previously synced artifacts, but we do have a policy of allowing breaking changes every 15 pulpcore releases, the last one was 3.100 (3.85 before that, 3.70, etc…). In these releases we can make breaking changes that we’ve planned before hand. The last major one was in 3.85 were we switch the STORAGES setting to being required, see [0]. We announce breaking changes in our changelog, so I would read that first. [1]
5. Besides backing up the database folder, you should also periodically back up the other Pulp folders as well just in case something goes wrong. As for minimal downtime, we have a policy that upgrades should (when possible) be zero-downtime compatible. This means you can run old Pulp instances and new Pulp instances at the same time! So for step 2 in the upgrade procedure instead of stopping your running instance, you could start a new instance on a different port, but pointing to the same folders and check that it boots and is responsive. This will cause the database migrations to run for the new version, but don’t worry your old Pulp instance that is still running will continue to work! Once you are satisfied that the new version is working properly, you can stop the old instance and reboot it onto the new version. Since the migrations have already ran it should boot up very quickly minimizing your downtime.

Let me know if you have any questions or run into any issues.

[0] Settings - Pulp Project
[1] Changelog - Pulp Project

1 Like