-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
False
-
-
False
-
- The AAP operator has the ability to use either replace or rollingupdates strategies when replacing pods for AAP.
- Customers can define the strategy preferred in the AAP CR.
Goals
- Reduce AAP downtime during operator upgrades and pod replacement operations.
Background and strategic fit
Summary
It should be possible to define the update strategy of deployments of the custom resources the operator deploys so that a strategy of "RollingUpdates" can be used as opposed to it utilizing the recreate strategy.
Problem Description
The replace strategy brute force replaces all pods at the same time, causing a platform outage. A rolling strategy would, in theory, keep the platform running while pods are updated.
Assumptions
- That a rolling strategy is possible and doesn't cause inadvertent issues elsewhere, like DB schema changes.
User Story Requirements
| # | Title | User Story | Persona | Importance | Notes |
|---|---|---|---|---|---|
| 1 | Rolling Update Strategy | As an AAP administrator on OCP the operator uses a rolling strategy for pod replacement so that platform downtime is limited during these operations | major |
End to End Test
- Deploy AAP using the operator in OpenShift
- Release a new version of AAP operator
- Watch the pod lifecycle in the AAP namespace.
- Approve the install plan for the new operator
- Pods for individual components then get replaced in a rolling order.
If the previous steps are possible, then the test succeeds. Otherwise, the test fails.
- is related to
-
-
- Backlog
-