Project

Profile

Help

Story #7120

closed

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 over 3 years ago. Updated about 2 years ago.

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

0%

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

Description

Ticket moved to GitHub: "pulp/pulpcore/1915":https://github.com/pulp/pulpcore/issues/1915


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
Actions #1

Updated by fao89 over 3 years 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?

Actions #2

Updated by mdellweg over 3 years 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.

Actions #3

Updated by ipanova@redhat.com over 3 years ago

  • Tags Documentation added
Actions #4

Updated by pulpbot about 2 years ago

  • Description updated (diff)
  • Status changed from NEW to CLOSED - DUPLICATE

Also available in: Atom PDF