Add update-target-stage gate annotation#1913
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ciecierski The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
OpenStackControlPlane CRD Size Report
Threshold reference
|
stuggi
left a comment
stuggi
left a comment
There was a problem hiding this comment.
I think we might want to add webhook validation for the annotation values, like validating the annotation value in the ValidateUpdate webhook on OpenStackVersion . If someone sets target-stage=tyop, the webhook rejects the update immediately with a clear error, rather than silently ignoring it and not would run a full update.
The OpenStackVersion already has a webhook. Adding a check like:
if stage, ok := r.Annotations[MinorUpdateTargetStageAnnotation]; ok {
validStages := map[string]bool{...}
if !validStages[stage] {
return Forbidden("invalid target stage")
}
}
|
Build failed (check pipeline). Post ❌ openstack-k8s-operators-content-provider FAILURE in 7m 30s |
ciecierski
force-pushed
the
staged-update
branch
2 times, most recently
from
49cecea to
1ed02a9
Compare
ciecierski
changed the title
|
/test functional |
1 similar comment
|
/test functional |
|
What happens if...
Stage D's condition would be reset to |
We have two alternatives either let user set annotation for stage C and let user fix it with fixed oc patch. Or as you mentioned set webook to block user from making this kind of harmless mistake(setting annotations with stage C won't rollback updated containers in stage D) . |
|
/retest-required |
ciecierski
force-pushed
the
staged-update
branch
3 times, most recently
from
fae4854 to
6bda39d
Compare
|
/retest-required |
Introduce a core.openstack.org/update-target-stage annotation on OpenStackVersion. When set, the update controller completes all stages up to and including the named stage, marks the next stage as blocked (FalseCondition/RequestedReason), and pauses reconciliation. Removing the annotation or advancing it to a later stage resumes the update. Includes stage-name constants, the gated-message format string, controller logic for all seven stages, functional tests for block/resume/ advance scenarios, webhooks and updated operator documentation. AI-assisted: Cursor (Claude Sonnet 4.6 by Anthropic)
| The recommended approach is to set the annotation to the first stage before bumping | ||
| `targetVersion`, then advance the annotation one stage at a time after you have validated | ||
| each step. If you start the update without the annotation, you cannot add it later at a | ||
| stage earlier than rollout progress already reached; set a later stage or remove the | ||
| annotation to run to completion. |
There was a problem hiding this comment.
As it says "The recommended approach" , does it mean if you use the staged approach you should start with the first stage, or does it mean that we want users to use the staged approach per default. If we want that the staged approach is the default, should the osversion controller add the annotation of the first stage per default, if someone bumps the targetVersion?
| | `mariadb` | MariaDB/Galera images | No | | ||
| | `memcached` | Memcached images | No | | ||
| | `keystone` | Keystone API images | No | | ||
| | `controlplane` | All remaining control-plane services | No | |
There was a problem hiding this comment.
I am wondering if this stage makes sense. the openstackversion controller would stop setting/checking if the dataplane was updated, but it would not block the user to actually update the dataplane by creating the dataplanedeployment. Do I miss a scenario where this stage is needed?
3 participants
Introduce the core.openstack.org/update-target-stage annotation on OpenStackVersion. When set, the minor update controller completes all stages up to and including the named stage, marks the next stage as blocked (FalseCondition/RequestedReason), and pauses reconciliation. Removing the annotation or advancing it to a later stage resumes the update. Includes stage-name constants, the gated-message format string, controller logic for all seven stages, webhook validation and functional tests for block/resume/ advance scenarios, and updated operator documentation.
AI-assisted: Cursor (Claude Sonnet 4.6 by Anthropic)