OCPCLOUD-3507: Add OTE e2e tests for ClusterAPIMachineManagement feature gate#606
OCPCLOUD-3507: Add OTE e2e tests for ClusterAPIMachineManagement feature gate#606pmeida wants to merge 1 commit into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@pmeida: This pull request references OCPCLOUD-3507 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. |
|
Warning Review limit reached
Next review available in: 8 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (3)
📒 Files selected for processing (5)
WalkthroughA new feature-gated end-to-end suite verifies Cluster API operator and controller health, CRD establishment, and management-cluster kubeconfig Secret readiness. Supporting deployment helpers, framework constants, and module requirements are added. ChangesCluster API readiness
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant E2ESuite
participant KubernetesAPI
participant ClusterAPIResources
E2ESuite->>KubernetesAPI: poll deployment and ClusterOperator conditions
KubernetesAPI->>ClusterAPIResources: read CRDs and kubeconfig Secret
ClusterAPIResources-->>E2ESuite: report readiness and Secret data
Suggested reviewers: 🚥 Pre-merge checks | ✅ 12 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (12 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
/ok-to-test |
openshift-ci
Bot
added
the
ok-to-test
|
To confirm if e2e tests go trough |
|
@pmeida: trigger 0 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command |
|
@pmeida: trigger 0 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command |
|
/payload-job-with-prs periodic-ci-openshift-release-main-nightly-5.0-e2e-aws-ovn-single-node-techpreview-serial openshift/origin#31307 |
|
@pmeida: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/7d80c200-6ef1-11f1-8a6b-01a933de5987-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-nightly-5.0-e2e-aws-ovn-single-node-techpreview openshift/origin#31307 |
|
@pmeida: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/f9d50680-6f15-11f1-876b-e0aef72228f3-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-nightly-5.0-e2e-aws-ovn-single-node-techpreview openshift/origin#31307 |
|
@pmeida: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/0da6c440-6f17-11f1-88d3-1d650fa5fcee-0 |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-5.0-e2e-aws-ovn-techpreview openshift/origin#31307 |
|
@pmeida: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/ccc72ee0-6f18-11f1-8b1e-eefb4a048f63-0 |
OTE run validation. Has to be done like this until we get the origin PR merged. Afterwards, we can also see OTE tests run through the |
from: periodic-ci-openshift-release-main-ci-5.0-e2e-aws-ovn-techpreview All OTE tests passing ✅ |
| Context("Provider images & initialization", func() { | ||
| It("should have the capi-installer-images ConfigMap present", func() { | ||
| cm := &corev1.ConfigMap{} | ||
| Expect(cl.Get(ctx, client.ObjectKey{ | ||
| Name: framework.CAPIInstallerImagesConfigMapName, | ||
| Namespace: framework.CAPIOperatorNamespace, | ||
| }, cm)).To(Succeed()) | ||
| Expect(cm.Data).NotTo(BeEmpty()) | ||
| }) | ||
| }) |
There was a problem hiding this comment.
I would prefer we did not test this in an e2e. It's an implementation detail which may change without affecting the readiness of the component. And if it was not present, all the other e2es would also fail anyway. I think this is noise.
There was a problem hiding this comment.
You are absolutely right!
I was trying to extend the tests to 10. So I proposed this in the PR waiting for possible negative feedback.
5 tests are enough to fulfil the promotion requirements.
| }).WithTimeout(framework.WaitMedium).WithPolling(framework.RetryMedium).Should(Succeed()) | ||
| }) | ||
|
|
||
| It("should have the cluster-api ClusterOperator reporting healthy", func() { |
There was a problem hiding this comment.
Do we need this? I guess it doesn't hurt, but a failure here would definitely trigger other failures. I wonder if it's redundant. @simkam thoughts?
There was a problem hiding this comment.
I kept it for now. A deployment being Available and a ClusterOperator reporting healthy are two different signals. It also is the primary user-visible health indicator for the stack, so verifying the operator writes it correctly seemed worth the test.
what do you think @simkam
|
/test e2e-aws-capi-techpreview |
|
/payload-job-with-prs periodic-ci-openshift-release-main-ci-5.0-e2e-aws-ovn-techpreview openshift/origin#31307 |
|
@pmeida: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/d19fcd00-70ad-11f1-9de7-ebc4da7c8a95-0 |
|
ci/prow/e2e-aws-capi-techpreview flake addressed in #610 |
|
/test e2e-aws-capi-techpreview |
|
new flake addressed in #611 |
|
/test e2e-aws-capi-techpreview |
|
/assign @mdbooth |
|
/pipeline required |
|
Scheduling tests matching the |
|
/retest |
|
[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 |
|
/retest |
|
/test ci/prow/okd-scos-images |
|
/test okd-scos-images |
|
/pipeline required |
|
Scheduling tests matching the |
…ure gate Add 10 non-disruptive health-check tests registered with the OTE binary that validate the Cluster API stack is correctly installed and operational when the ClusterAPIMachineManagement feature gate is enabled. Tests provide the Sippy signal required for feature gate promotion. Tests (all blocking, capio/parallel): - capi-operator deployment available in openshift-cluster-api-operator - cluster-api ClusterOperator reporting Available, not Degraded, not Progressing - capi-controllers deployment available in openshift-cluster-api - capi-installer deployment available in openshift-cluster-api-operator - capi-installer-images ConfigMap present in openshift-cluster-api-operator - Core CAPI CRDs (clusters, machines, machinesets) installed and established - Platform-specific infrastructure CRDs installed (derived from Cluster.Spec.InfrastructureRef) - Management Cluster object present with InfrastructureReady=True - Platform-specific infrastructure cluster object present (AWSCluster etc.) - Management cluster kubeconfig Secret present Platform-specific tests derive the infra Kind from the live Cluster object's InfrastructureRef rather than a hardcoded platform map, so no code changes are needed when new platforms are added. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
|
@pmeida: all tests passed! 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. |
|
/test e2e-aws-capi-techpreview |
4 participants
Summary
Adds 8 non-disruptive health-check e2e tests registered with the OTE binary that validate the Cluster API stack is correctly installed and operational when the
ClusterAPIMachineManagementfeature gate is enabled. These tests provide the Sippy signal required for feature gate promotion.Tests
All tests are
blocking,capio/parallel → openshift/conformance/parallel:Design notes
bin/cluster-capi-operator-tests-ext run-suite capio/paralleland viamake e2eDependencies
Summary by CodeRabbit
Summary by CodeRabbit
Tests
Chores