OCPBUGS-87001: Move installer and revision controllers to their own deployment#576
OCPBUGS-87001: Move installer and revision controllers to their own deployment#576mdbooth wants to merge 2 commits into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@mdbooth: This pull request references OCPCLOUD-3443 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThe PR extracts an installer into a new capi-installer binary/workload, adds manifests (ServiceAccount, Service, ServiceMonitor, ClusterRoleBinding, provider-images ConfigMap, Deployments, NetworkPolicy updates), introduces provider-image helpers, and implements InstallerDeploymentReconciler plus tests to build and SSA-apply a capi-installer Deployment from image refs. ChangesInstaller Separation and Deployment Management
Sequence Diagram(s)sequenceDiagram
participant ConfigMap as "capi-installer-images ConfigMap"
participant ClusterAPI as "ClusterAPI singleton"
participant API_Server as "Kubernetes API Server"
participant Reconciler as "InstallerDeploymentReconciler"
ConfigMap->>API_Server: update/create
ClusterAPI->>API_Server: status update
API_Server->>Reconciler: watch events (ConfigMap/ClusterAPI/Deployment)
Reconciler->>API_Server: GET ConfigMap
Reconciler->>API_Server: GET ClusterAPI
Reconciler->>Reconciler: build Desired Deployment (container image + image-backed volumes)
Reconciler->>API_Server: Server-Side Apply Deployment (fieldManager + Force)
API_Server->>Reconciler: apply result / status
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 11❌ Failed checks (1 warning, 10 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Nitpick comments (2)
pkg/controllers/installerdeployment/controller_test.go (1)
250-255: ⚡ Quick winUse
apierrors.IsNotFoundfor precise deletion verification.The check
err != nilcould match any error type, not specifically confirming the Deployment was deleted. Useapierrors.IsNotFound(err)for precise verification.♻️ Proposed fix
+ apierrors "k8s.io/apimachinery/pkg/api/errors"Eventually(func() bool { err := cl.Get(ctx, client.ObjectKey{Name: deploymentName, Namespace: namespace}, deployment) - return err != nil + return apierrors.IsNotFound(err) }).WithTimeout(testTimeout).WithPolling(testInterval).Should(BeTrue())🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pkg/controllers/installerdeployment/controller_test.go` around lines 250 - 255, The test's Eventually block currently returns err != nil which can be any error; update the predicate to explicitly check for deletion by returning apierrors.IsNotFound(err) from the closure that calls cl.Get(ctx, client.ObjectKey{Name: deploymentName, Namespace: namespace}, deployment). Also add the required import for "k8s.io/apimachinery/pkg/api/errors" (alias apierrors) so the test compiles and precisely verifies the Deployment was deleted.pkg/controllers/installerdeployment/suite_test.go (1)
38-40: 💤 Low valueUnused constant
testNamespace.The
testNamespaceconstant is defined but never used in the test suite. The actual tests incontroller_test.gogenerate unique namespaces withGenerateName. Consider removing this unused constant.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pkg/controllers/installerdeployment/suite_test.go` around lines 38 - 40, The constant testNamespace in suite_test.go is unused; remove the unused declaration (testNamespace) from the file or, if intended for tests, replace usage so tests reference testNamespace instead of generating namespaces via GenerateName in controller_test.go; update any imports/comments accordingly to keep the file clean.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@manifests/0000_30_cluster-api-operator_06_deployment.yaml`:
- Around line 29-62: The capi-operator container is missing a hardened
securityContext and resource limits; update the container spec for the container
named "capi-operator" to add a container-level securityContext with
allowPrivilegeEscalation: false, runAsNonRoot: true, readOnlyRootFilesystem:
true, and capabilities: drop: ["ALL"], and add resources.limits (cpu and memory)
alongside the existing resources.requests (e.g., set limits slightly above
requests) so both cpu and memory have requests and limits defined.
- Around line 75-84: The manifest uses a hard nodeSelector and broad tolerations
("nodeSelector", tolerations with keys "node-role.kubernetes.io/control-plane"
and "node-role.kubernetes.io/master") which force pods onto control-plane nodes
and reduces scheduling resilience; replace the hard nodeSelector with a softer
nodeAffinity (preferredDuringSchedulingIgnoredDuringExecution) targeting
control-plane nodes and/or use an explicit nodeAffinity nodeSelectorTerm that
excludes arbiter nodes (e.g. a DoesNotExist check for an arbiter label) and
tighten/remove the broad tolerations so the Deployment does not indiscriminately
tolerate all control-plane taints; update the Deployment spec (where
nodeSelector and tolerations are declared) to use nodeAffinity preferences and
more specific tolerations instead.
In `@pkg/controllers/installerdeployment/assets/deployment.yaml`:
- Around line 66-75: The manifest currently hard-pins pods to control-plane
nodes by setting nodeSelector: node-role.kubernetes.io/control-plane and adding
master/control-plane NoSchedule tolerations; remove the nodeSelector block and
the two tolerations (or replace them with a non-control-plane-specific
scheduling rule such as a generic nodeSelector or preferredDuringScheduling
affinity) so pods are not forced onto control-plane/arbiter nodes; update any
related comments and ensure restartPolicy: Always remains unchanged while
testing on both HA and single-node clusters.
- Around line 23-53: Add container hardening and resource limits to the
capi-installer container spec: under the container named "capi-installer" add a
securityContext with runAsNonRoot: true, readOnlyRootFilesystem: true,
allowPrivilegeEscalation: false and capabilities: drop: ["ALL"]; also add
resource.limits (matching or slightly above existing requests) for cpu and
memory to complement the existing requests (e.g., cpu and memory limits) so
every container has both requests and limits defined.
In `@pkg/controllers/installerdeployment/deployment.go`:
- Around line 109-143: The volumeNameForImageRef function can produce names
longer than Kubernetes' 63-character DNS-label limit, causing Deployment
rejections; update volumeNameForImageRef so the final name is DNS-label
compliant and <=63 chars before returning. Keep the shortHash and separator
intact by computing maxImageNameLen = 63 - 1 - len(shortHash) (for the hyphen),
truncate the sanitized imageName to that length, then build volumeName =
fmt.Sprintf("%s-%s", truncatedImageName, shortHash). After prefixing with "img-"
when needed (if first char isn't alphanumeric), re-check length and if >63,
truncate the imageName portion further to ensure total <=63. Also ensure the
final name starts and ends with an alphanumeric character (trim trailing '-'
from the imageName portion if necessary) so the returned value (used as
corev1.Volume.Name and corev1.VolumeMount.Name in buildDesiredDeployment) always
meets Kubernetes DNS-label rules.
In `@pkg/providerimages/configmap_test.go`:
- Around line 62-66: The test in ImageRefsFromConfigMap should assert the exact
error value instead of substring matching; replace the err.Error() +
ContainSubstring assertion with a Gomega MatchError against the predefined
errConfigMapNil (e.g., change the assertion to
Expect(err).To(MatchError(errConfigMapNil))) while keeping the call to
ImageRefsFromConfigMap(nil) and the Expect(result).To(BeNil()) assertion;
reference the ImageRefsFromConfigMap function and the errConfigMapNil error
constant when making this change.
---
Nitpick comments:
In `@pkg/controllers/installerdeployment/controller_test.go`:
- Around line 250-255: The test's Eventually block currently returns err != nil
which can be any error; update the predicate to explicitly check for deletion by
returning apierrors.IsNotFound(err) from the closure that calls cl.Get(ctx,
client.ObjectKey{Name: deploymentName, Namespace: namespace}, deployment). Also
add the required import for "k8s.io/apimachinery/pkg/api/errors" (alias
apierrors) so the test compiles and precisely verifies the Deployment was
deleted.
In `@pkg/controllers/installerdeployment/suite_test.go`:
- Around line 38-40: The constant testNamespace in suite_test.go is unused;
remove the unused declaration (testNamespace) from the file or, if intended for
tests, replace usage so tests reference testNamespace instead of generating
namespaces via GenerateName in controller_test.go; update any imports/comments
accordingly to keep the file clean.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 42ea6dfb-6f8e-4e0e-ac90-0387c7e999b1
📒 Files selected for processing (29)
Dockerfile.rhelMakefilecmd/capi-installer/main.gocmd/capi-operator/main.gomanifests/0000_30_cluster-api-installer_05_deployment.yamlmanifests/0000_30_cluster-api-operator_00_namespace.yamlmanifests/0000_30_cluster-api-operator_00_tombstones.yamlmanifests/0000_30_cluster-api-operator_01_metrics-service.yamlmanifests/0000_30_cluster-api-operator_01_serviceaccount.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-metrics-service.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-serviceaccount.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-servicemonitor.yamlmanifests/0000_30_cluster-api-operator_03_clusterrole.yamlmanifests/0000_30_cluster-api-operator_04_capi-installer-clusterrolebinding.yamlmanifests/0000_30_cluster-api-operator_04_clusterrolebinding.yamlmanifests/0000_30_cluster-api-operator_05_provider-images-configmap.yamlmanifests/0000_30_cluster-api-operator_06_deployment.yamlmanifests/0000_30_cluster-api-operator_07_clusterapi.yamlpkg/controllers/installerdeployment/assets/deployment.yamlpkg/controllers/installerdeployment/controller.gopkg/controllers/installerdeployment/controller_test.gopkg/controllers/installerdeployment/deployment.gopkg/controllers/installerdeployment/deployment_test.gopkg/controllers/installerdeployment/suite_test.gopkg/providerimages/configmap.gopkg/providerimages/configmap_test.gopkg/providerimages/providerimages_test.gopkg/providerimages/revision_images.gopkg/providerimages/revision_images_test.go
💤 Files with no reviewable changes (1)
- manifests/0000_30_cluster-api-installer_05_deployment.yaml
| nodeSelector: | ||
| node-role.kubernetes.io/control-plane: "" | ||
| restartPolicy: Always | ||
| tolerations: | ||
| - key: "node-role.kubernetes.io/master" | ||
| operator: "Exists" | ||
| effect: "NoSchedule" | ||
| - key: "node-role.kubernetes.io/control-plane" | ||
| operator: "Exists" | ||
| effect: "NoSchedule" |
There was a problem hiding this comment.
Revisit hard control-plane scheduling constraints.
Hard control-plane nodeSelector plus master/control-plane tolerations assume a specific topology and can reduce scheduling resilience on variant cluster layouts.
As per coding guidelines, "**/*.{go,yaml,yml,json} ... Flag ... nodeSelector/affinity targeting control-plane nodes ... scheduling to all control-plane nodes without excluding arbiter nodes."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@manifests/0000_30_cluster-api-operator_06_deployment.yaml` around lines 75 -
84, The manifest uses a hard nodeSelector and broad tolerations ("nodeSelector",
tolerations with keys "node-role.kubernetes.io/control-plane" and
"node-role.kubernetes.io/master") which force pods onto control-plane nodes and
reduces scheduling resilience; replace the hard nodeSelector with a softer
nodeAffinity (preferredDuringSchedulingIgnoredDuringExecution) targeting
control-plane nodes and/or use an explicit nodeAffinity nodeSelectorTerm that
excludes arbiter nodes (e.g. a DoesNotExist check for an arbiter label) and
tighten/remove the broad tolerations so the Deployment does not indiscriminately
tolerate all control-plane taints; update the Deployment spec (where
nodeSelector and tolerations are declared) to use nodeAffinity preferences and
more specific tolerations instead.
| containers: | ||
| - name: capi-installer | ||
| command: | ||
| - /capi-installer | ||
| args: | ||
| - --diagnostics-address=:8443 | ||
| env: | ||
| - name: POD_NAME | ||
| valueFrom: | ||
| fieldRef: | ||
| fieldPath: metadata.name | ||
| - name: POD_NAMESPACE | ||
| valueFrom: | ||
| fieldRef: | ||
| fieldPath: metadata.namespace | ||
| ports: | ||
| - containerPort: 9440 | ||
| name: health | ||
| protocol: TCP | ||
| - containerPort: 8443 | ||
| name: diagnostics | ||
| protocol: TCP | ||
| resources: | ||
| requests: | ||
| cpu: 10m | ||
| memory: 50Mi | ||
| terminationMessagePolicy: FallbackToLogsOnError | ||
| volumeMounts: | ||
| - name: metrics-cert | ||
| mountPath: /tmp/k8s-metrics-server/serving-certs | ||
| readOnly: true |
There was a problem hiding this comment.
Add explicit container hardening and resource limits.
The container spec is missing explicit securityContext hardening (runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, drop ALL capabilities), and it defines requests without limits.
As per coding guidelines, "**/*.{yaml,yml}: securityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false; Drop ALL capabilities ... Resource limits (cpu, memory) on every container."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@pkg/controllers/installerdeployment/assets/deployment.yaml` around lines 23 -
53, Add container hardening and resource limits to the capi-installer container
spec: under the container named "capi-installer" add a securityContext with
runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation:
false and capabilities: drop: ["ALL"]; also add resource.limits (matching or
slightly above existing requests) for cpu and memory to complement the existing
requests (e.g., cpu and memory limits) so every container has both requests and
limits defined.
There was a problem hiding this comment.
Which coding guidelines?
There was a problem hiding this comment.
@mdbooth, these come from the CodeRabbit path-based review instructions configured for this repository, applied to all **/*.{yaml,yml} files. The relevant rule is:
If this is a Kubernetes/OpenShift manifest or Helm template:
securityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false- Drop ALL capabilities, add only what is required
- Resource limits (cpu, memory) on every container
That said, it's worth noting that the manifest already sets openshift.io/required-scc: restricted-v2, which enforces many of these constraints at the OpenShift admission layer (no privilege escalation, run as non-root, etc.). If your team considers that annotation sufficient for this operator's deployment context, or if the SCC enforcement makes the explicit securityContext fields redundant by policy, I can acknowledge that and move on. Would you like me to resolve this comment or dismiss it?
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pkg/controllers/installerdeployment/controller.go (1)
167-167: 💤 Low valueConfigMap watch triggers on all ConfigMaps cluster-wide.
The
Watchesfor ConfigMap lacks a namespace predicate, so every ConfigMap create/update/delete in any namespace will invokemapConfigMapToReconcile. While the map function filters correctly, this generates unnecessary API server traffic and reconcile evaluations.Consider adding a predicate to filter by namespace:
♻️ Suggested improvement
- Watches(&corev1.ConfigMap{}, handler.EnqueueRequestsFromMapFunc(r.mapConfigMapToReconcile)). + Watches(&corev1.ConfigMap{}, handler.EnqueueRequestsFromMapFunc(r.mapConfigMapToReconcile), + builder.WithPredicates(predicate.NewPredicateFuncs(func(obj client.Object) bool { + return obj.GetNamespace() == r.Namespace && obj.GetName() == configMapName + }))).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@pkg/controllers/installerdeployment/controller.go` at line 167, The ConfigMap watch currently registers cluster-wide (Watches(&corev1.ConfigMap{}, handler.EnqueueRequestsFromMapFunc(r.mapConfigMapToReconcile))) causing reconciles for all namespaces; restrict the watch by adding a namespace predicate that only allows events from the controller's target namespace (e.g., use predicate.NewPredicateFuncs or predicate.Funcs comparing obj.GetNamespace() to r.namespace) so that Watches only enqueues when the ConfigMap namespace matches, leaving mapConfigMapToReconcile unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@pkg/controllers/installerdeployment/controller.go`:
- Line 167: The ConfigMap watch currently registers cluster-wide
(Watches(&corev1.ConfigMap{},
handler.EnqueueRequestsFromMapFunc(r.mapConfigMapToReconcile))) causing
reconciles for all namespaces; restrict the watch by adding a namespace
predicate that only allows events from the controller's target namespace (e.g.,
use predicate.NewPredicateFuncs or predicate.Funcs comparing obj.GetNamespace()
to r.namespace) so that Watches only enqueues when the ConfigMap namespace
matches, leaving mapConfigMapToReconcile unchanged.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: dfdc8e5a-b67d-4ace-81e2-95d35f883d14
📒 Files selected for processing (29)
Dockerfile.rhelMakefilecmd/capi-installer/main.gocmd/capi-operator/main.gomanifests/0000_30_cluster-api-installer_05_deployment.yamlmanifests/0000_30_cluster-api-operator_00_namespace.yamlmanifests/0000_30_cluster-api-operator_00_tombstones.yamlmanifests/0000_30_cluster-api-operator_01_metrics-service.yamlmanifests/0000_30_cluster-api-operator_01_serviceaccount.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-metrics-service.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-serviceaccount.yamlmanifests/0000_30_cluster-api-operator_02_capi-installer-servicemonitor.yamlmanifests/0000_30_cluster-api-operator_03_clusterrole.yamlmanifests/0000_30_cluster-api-operator_04_capi-installer-clusterrolebinding.yamlmanifests/0000_30_cluster-api-operator_04_clusterrolebinding.yamlmanifests/0000_30_cluster-api-operator_05_provider-images-configmap.yamlmanifests/0000_30_cluster-api-operator_06_deployment.yamlmanifests/0000_30_cluster-api-operator_07_clusterapi.yamlpkg/controllers/installerdeployment/assets/deployment.yamlpkg/controllers/installerdeployment/controller.gopkg/controllers/installerdeployment/controller_test.gopkg/controllers/installerdeployment/deployment.gopkg/controllers/installerdeployment/deployment_test.gopkg/controllers/installerdeployment/suite_test.gopkg/providerimages/configmap.gopkg/providerimages/configmap_test.gopkg/providerimages/providerimages_test.gopkg/providerimages/revision_images.gopkg/providerimages/revision_images_test.go
💤 Files with no reviewable changes (1)
- manifests/0000_30_cluster-api-installer_05_deployment.yaml
✅ Files skipped from review due to trivial changes (1)
- pkg/controllers/installerdeployment/deployment_test.go
🚧 Files skipped from review as they are similar to previous changes (16)
- Dockerfile.rhel
- Makefile
- manifests/0000_30_cluster-api-operator_02_capi-installer-servicemonitor.yaml
- manifests/0000_30_cluster-api-operator_05_provider-images-configmap.yaml
- pkg/providerimages/revision_images.go
- pkg/providerimages/configmap.go
- manifests/0000_30_cluster-api-operator_02_capi-installer-serviceaccount.yaml
- manifests/0000_30_cluster-api-operator_04_capi-installer-clusterrolebinding.yaml
- pkg/providerimages/configmap_test.go
- cmd/capi-installer/main.go
- pkg/providerimages/revision_images_test.go
- manifests/0000_30_cluster-api-operator_06_deployment.yaml
- pkg/controllers/installerdeployment/deployment.go
- cmd/capi-operator/main.go
- pkg/providerimages/providerimages_test.go
- pkg/controllers/installerdeployment/controller_test.go
|
/pipeline auto |
|
Pipeline controller notification The |
|
unit test failure is the same flake fixed by #578 /test unit |
|
Scheduling tests matching the |
|
Pipeline controller has died again. Lets try to kick it manually. /pipeline required |
|
Scheduling tests matching the |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
/pipeline required |
|
Scheduling tests matching the |
|
Scheduling tests matching the |
|
Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage. |
2 similar comments
|
Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage. |
|
Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage. |
|
Scheduling tests matching the |
mdbooth
changed the title
openshift-ci-robot
added
jira/severity-important
|
@mdbooth: This pull request references Jira Issue OCPBUGS-87001, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@mdbooth: This pull request references Jira Issue OCPBUGS-87001, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Look like flakes: Permafailing: |
|
@mdbooth: /override requires failed status contexts, check run or a prowjob name to operate on.
Only the following failed contexts/checkruns were expected:
If you are trying to override a checkrun that has a space in it, you must put a double quote on the context. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/override ci/prow/e2e-openstack-ovn-techpreview |
|
@mdbooth: Overrode contexts on behalf of mdbooth: ci/prow/e2e-openstack-ovn-techpreview DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/testwith openshift/cluster-capi-operator/main/e2e-azure-ovn-techpreview openshift/cluster-api-provider-azure#392 |
|
/testwith openshift/cluster-capi-operator/main/e2e-azure-ovn-techpreview-upgrade openshift/cluster-api-provider-azure#392 |
|
@mdbooth: Overrode contexts on behalf of mdbooth: ci/prow/e2e-openstack-ovn-techpreview DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@mdbooth: This pull request references Jira Issue OCPBUGS-87001, which is valid. 3 validation(s) were run on this bug
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/test e2e-aws-ovn-techpreview e2e-gcp-ovn-techpreview |
1 similar comment
|
/test e2e-aws-ovn-techpreview e2e-gcp-ovn-techpreview |
openshift/cluster-capi-operator#576 changes the name of the deployment which produces these events, which breaks the existing match. Also update the comment to note that the upstream fix merged and will be in 1.37.
|
openshift/origin#31286 has landed. /retest-required |
|
/test e2e-azure-ovn-techpreview |
|
@mdbooth: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
2 participants
Moves the installer and revision controllers into a separate
capi-installerdeployment which is created bycapi-operator.The reason for this is that these controllers mount release images as volumes. They will always mount the provider images from the current release, but on upgrade they must also mount the provider images from any previous revisions which are still active. Therefore the deployment cannot be static.
A new controller,
installerdeploymentruns incapi-operatorto create the installer deployment.Needs openshift/origin#31286 to merge before the e2es will pass.
Summary by CodeRabbit
New Features
Chores