🌱 Update registry+v1 revision phases#2520
🌱 Update registry+v1 revision phases#2520perdasilva wants to merge 1 commit intooperator-framework:mainfrom
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
…rdering Restructure the phase definitions to provide more granular control over the order in which Kubernetes resources are applied during extension installation. The previous coarse-grained phases (rbac, deploy, publish) are replaced with finer-grained phases that better reflect resource dependency chains and operational best practices. Phase changes: - Split "rbac" into "identity" (ServiceAccount), "roles" (ClusterRole, Role), and "bindings" (ClusterRoleBinding, RoleBinding) for explicit ordering of RBAC prerequisites before their bindings - Extract "configuration" phase (Secret, ConfigMap) from "deploy" so config resources are available before workloads that mount them - Extract "infrastructure" phase (Service, Issuer) from "deploy" so services and cert-manager issuers exist before workloads reference them - Add "scaling" phase (VerticalPodAutoscaler) after deploy for autoscaling policies to target running workloads - Add "admission" phase (ValidatingWebhookConfiguration, MutatingWebhookConfiguration) as the final phase so webhooks are registered only after their backing services are ready - Move CRDs before roles/bindings so RBAC rules referencing custom resources can be validated - Add cert-manager Certificate to "deploy" phase alongside Deployment - Add monitoring resources (PrometheusRule, ServiceMonitor, PodMonitor) and OpenShift console resources to "publish" phase - Remove explicit mappings for workload kinds that already default to "deploy" (DaemonSet, StatefulSet, ReplicaSet, Pod, Job, CronJob) New phase order: namespaces → policies → identity → configuration → storage → crds → roles → bindings → infrastructure → deploy → scaling → publish → admission Signed-off-by: Per G. da Silva <pegoncal@redhat.com>
There was a problem hiding this comment.
Pull request overview
Updates the operator-controller “revision phases” model to a more granular set of phases and refreshes phase sorting expectations accordingly.
Changes:
- Replaces RBAC/RBACBindings with Identity/Roles/Bindings and adds new phases (Configuration/Infrastructure/Scaling/Admission).
- Updates the GroupKind→Phase mapping to reflect the new phase taxonomy and ordering.
- Adjusts unit tests for phase sorting and revision generation to match the new phase outputs.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| internal/operator-controller/applier/phase.go | Introduces new phases and updates default ordering + GroupKind phase mappings. |
| internal/operator-controller/applier/phase_test.go | Updates phase sort test cases and expectations for the new phase breakdown. |
| internal/operator-controller/applier/boxcutter_test.go | Updates revision generator tests to expect objects split across the new phases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| PhasePolicies: { | ||
| {Kind: "ResourceQuota"}, | ||
| {Kind: "LimitRange"}, | ||
| {Kind: "PriorityClass", Group: "scheduling.k8s.io"}, | ||
| {Kind: "NetworkPolicy", Group: "networking.k8s.io"}, | ||
| {Kind: "HorizontalPodAutoscaler", Group: "autoscaling"}, | ||
| {Kind: "PodDisruptionBudget", Group: "policy"}, | ||
| {Kind: "PriorityClass", Group: "scheduling.k8s.io"}, | ||
| }, |
There was a problem hiding this comment.
HorizontalPodAutoscaler was removed from the phase mappings (it previously had an explicit phase). With the introduction of PhaseScaling, it likely belongs there; otherwise HPAs will fall back to the default/unknown behavior and may be applied later than intended. Consider adding {Kind: "HorizontalPodAutoscaler", Group: "autoscaling"} under PhaseScaling (or another explicit phase) to preserve deterministic ordering for autoscaling resources.
| }, | ||
|
|
||
| PhaseScaling: { | ||
| {Kind: "VerticalPodAutoscaler", Group: "autoscaling.k8s.io"}, |
There was a problem hiding this comment.
HorizontalPodAutoscaler was removed from the phase mappings (it previously had an explicit phase). With the introduction of PhaseScaling, it likely belongs there; otherwise HPAs will fall back to the default/unknown behavior and may be applied later than intended. Consider adding {Kind: "HorizontalPodAutoscaler", Group: "autoscaling"} under PhaseScaling (or another explicit phase) to preserve deterministic ordering for autoscaling resources.
| {Kind: "VerticalPodAutoscaler", Group: "autoscaling.k8s.io"}, | |
| {Kind: "VerticalPodAutoscaler", Group: "autoscaling.k8s.io"}, | |
| {Kind: "HorizontalPodAutoscaler", Group: "autoscaling"}, |
| {Kind: "NetworkPolicy", Group: "networking.k8s.io"}, | ||
| {Kind: "HorizontalPodAutoscaler", Group: "autoscaling"}, | ||
| {Kind: "PodDisruptionBudget", Group: "policy"}, | ||
| {Kind: "PriorityClass", Group: "scheduling.k8s.io"}, |
There was a problem hiding this comment.
This change drops ResourceQuota and LimitRange from the explicit phase mappings. If these objects are still expected to be ordered early (they’re typically part of cluster/namespace policy setup), consider keeping them mapped in PhasePolicies so their phase assignment remains explicit and resilient to changes in any fallback logic.
| {Kind: "PriorityClass", Group: "scheduling.k8s.io"}, | |
| {Kind: "PriorityClass", Group: "scheduling.k8s.io"}, | |
| {Kind: "ResourceQuota"}, | |
| {Kind: "LimitRange"}, |
perdasilva
force-pushed
the
regv1-phase-deployment
branch
from
e7b39fb to
110babe
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2520 +/- ##
==========================================
- Coverage 73.27% 69.49% -3.79%
==========================================
Files 103 103
Lines 8516 8516
==========================================
- Hits 6240 5918 -322
- Misses 1801 2129 +328
+ Partials 475 469 -6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
1 participant
Description
Restructures the registry+v1 revision phase definitions to provide more granular control over the order in which Kubernetes resources are applied during extension installation.
The previous coarse-grained phases (
rbac,deploy,publish) are replaced with finer-grained phases that better reflect resource dependency chains and operational best practices.Phase changes
rbacidentityrbacrolesrbac-bindingsbindingsdeploy(partial)configurationdeploy(partial)infrastructurescalingpublish(partial)admissionNew phase order
Key design decisions
identity), then role definitions (roles), then bindings (bindings), ensuring prerequisites exist before being referencedconfigurationbeforedeploy, so Pods can mount them immediatelyinfrastructurebeforedeploy, so workloads can reference themroles/bindingsso RBAC rules referencing custom resources can be validatedpublishphasedeployphaseReviewer Checklist