Project

Profile

Help

Story #7120

As a plugin developer, I have docs that require me to support zero-downtime upgrades and docs explaining how to do so

Added by bmbouter about 1 month ago. Updated 29 days ago.

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

0%

Estimated time:
Platform Release:
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:

Description

Background

Zero downtime migrations are needed for the following reasons:

  • the operator facilitating the current upgrade process will be very difficult. Do-able but difficult
  • downtime is very undesirable
  • the installer struggles to support this today, and as it moves more into clustered installs it will become increasing complex

So the goal is to take the current upgrade process with is:

  1. Stop all services
  2. Upgrade code
  3. Run migrations
  4. Start all services

To one like this:

  1. Upgrade code
  2. Run migrations
  3. Restart all services

Proposal

Have pulpcore and plugin writers ship migrations which require zero-downtime.

How to do this?

These articles outline it pretty well, but basically you need to split the migration into additive and destructive changes.

https://wxweekly.com/zero-downtime-deploys-a-tale-of-django-migrations-7a040f425e4a https://pypi.org/project/django-pg-zero-downtime-migrations/

The work to accomplish this

  1. Reach agreement with the pulp community through the mailing list
  2. Add to the plugin writer docs this requirement
  3. Add the migration checks to the CI recommended in https://wxweekly.com/zero-downtime-deploys-a-tale-of-django-migrations-7a040f425e4a

History

#1 Updated by fao89 29 days ago

Talking about "seamless upgrade" from operator, I think one pain we have is plugins requiring different versions of pulpcore.

Let's say I use pulp_file, pulp_container, and pulp_rpm, new pulpcore and pulp_file version are released. What the operator should do? Only update the pulpcore when all installed plugins support it?

#2 Updated by mdellweg 29 days ago

Part of the policy should be, that removals (destructive migrations) can only ever happen at major or minor releases. This would allow that you can always install the latest bugfix release of your current y-release. Maybe we need to claim that you can only upgrade seemlessly from the latest bugfix to the next minor version.

Please register to edit this issue

Also available in: Atom PDF