HPCASE-362: Promote TLSAdherence feature gate to GA - #2883
openshift-merge-bot[bot] merged 1 commit into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
Hello @joelanford! Some important instructions when contributing to openshift/api: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. 📝 WalkthroughWalkthroughThe change adds the optional Priority: ➖ Normal Merge Risk: ⚪ Minimal · up to TLSAdherence is consistently enabled for GA feature sets and exposes the expected validated API contract, with no remaining actionable merge risk identified. 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Warning Some tools did not complete. Review the errors below. 🔧 golangci-lint (2.13.2)Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented Comment |
|
This is speculative to see what gating criteria need to be added to https://redhat.atlassian.net/browse/HPCASE-362 |
|
/test ? |
|
@joelanford: This pull request references HPCASE-362 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 epic 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. |
|
@joelanford Is there on-going work to add tests for this feature? |
|
@everettraven We have a PR here openshift/origin#31309 that should be gtg. The current CI failures seem to be due to flakiness |
|
/test verify-feature-promotion |
9fce402 to
88d8373
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
/test verify-feature-promotion |
|
/test verify-feature-promotion |
You can now get an instantaneous view of the feature gate promotion through sippy, e.g. https://sippy.dptools.openshift.org/sippy-ng/feature_gates/5.0/TLSAdherence |
88d8373 to
559b4c5
Compare
|
/retest |
1 similar comment
|
/retest |
|
/test verify-feature-promotion AI-generated. Review for accuracy. |
|
@joelanford I think the only feature gate testing for TLSAdherence is in openshift/origin#31309, but that was closed before it merged. Was that intentional? I'm seeing this in the results for the job verify-feature-promotion, which seems to imply the feature is not being tested?
|
|
/pipeline required |
|
Scheduling tests matching the |
|
/override-sticky ci/prow/e2e-azure Automated triage: This failure appears unrelated to the PR changes. Job classification: Eligible long-running presubmit e2e/integration job. The Prow definition is Revision check: Run SHA Execution status: Tests executed. The Completed supporting jobs: Fleet-wide failure rate: This job passed 11/20 runs (55.0%) over the last 14 days. The root test had an 86.3% global pass rate with 473 flakes in 3,450 runs, and a 79.1% Azure pass rate with 152 flakes in 729 runs over the last 7 days. Open regressions: None found for Linked bugs: None linked to the root etcd leader-loss test. Overlap assessment: PR #2883 changes API/CRD and feature-gate manifests for promoting Missing-coverage risk: Low for this failure. The job completed its long-running Azure e2e coverage and failed only because of the known Azure etcd leader-loss condition. Accepting the override does not substitute this job for TLSAdherence-specific coverage, which is a separate signal. Prior bot activity on this SHA: Rationale: The current-HEAD run executed tests, the failure is a known high-rate Azure etcd flake, the failure cascaded into etcd timeout errors in other tests, and the PR has no plausible overlap with etcd leader stability. If you disagree with this assessment, rerun the current job with AI-generated. Review for accuracy. |
|
@redhat-chai-bot: Overrode contexts on behalf of redhat-chai-bot: ci/prow/e2e-azure These overrides will persist across retests on the current HEAD SHA. Pushing a new commit will clear them. Use 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. |
|
/pipeline required |
|
Scheduling tests matching the |
|
/override-sticky ci/prow/e2e-aws-ovn-hypershift-conformance Automated triage: This failure appears unrelated to the PR changes. Job classification: Eligible long-running presubmit e2e/integration job. The Prow definition uses the Revision check: Run SHA Execution status: Tests executed. The final summary recorded six blocking failures, all in AWS load-balancer/router/Gateway API coverage. The observed signatures were ELB reachability timeout, DNS/route resolution timeout, h2spec condition timeout, and interruption after the timeout cascade. The same job passed on the same SHA in earlier run Completed supporting jobs: Fleet-wide failure rate: The job pass rate is 72.4% over the last 30 days. Exact failing-test rates were: Open regressions: None found for the six failing tests in the relevant Component Readiness view. Linked bugs: Internal CI analysis found existing linked tracking for the observed AWS load-balancer/router failures. Jira identifiers and statuses are intentionally omitted from this public PR comment. Overlap assessment: The PR changes TLSAdherence feature-gate/API schema and generated manifests only. It does not change AWS load-balancer behavior, router/HAProxy, Gateway API, DNS, HyperShift provisioning, or test infrastructure. No plausible direct or indirect overlap with the observed failures was found. Missing-coverage risk: Low for this failure. The same PR revision passed the complete job earlier, all six failed tests passed in that run, and relevant build/unit/integration/verification and HyperShift/upgrade jobs completed successfully. Pending checks are not used as positive signal; they remain pending separately. Prior bot activity on this SHA: Rationale: The current-HEAD run executed tests, but the failures formed a correlated AWS/HyperShift networking timeout pattern and all six passed on the same SHA in the earlier run. The failure is unrelated to the PR's API/feature-gate changes. If you disagree with this assessment, rerun the current job with AI-generated. Review for accuracy. AI-generated. Review for accuracy. |
|
@redhat-chai-bot: Overrode contexts on behalf of redhat-chai-bot: ci/prow/e2e-aws-ovn-hypershift-conformance These overrides will persist across retests on the current HEAD SHA. Pushing a new commit will clear them. Use 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-sticky ci/prow/e2e-aws-ovn Automated triage: This failure appears unrelated to the PR changes. Job classification: Eligible long-running AWS OVN end-to-end presubmit. The definition uses the Revision check: event SHA Execution status: Tests executed. The live Prow log reports 2231 passed, 7 blocking failures, 1 informing failure, 0 flakes, and 2119 skipped. The failed tests were:
The dominant signatures are DNS/route resolution timeouts, condition timeouts, and Completed supporting jobs: Pending jobs: Fleet-wide failure rate: The exact presubmit job passed 2/8 runs over the last 7 days (25.0%); all eight runs were openshift/api PR runs. Release 5.1 test reports show: CLB hairpinning 98.69% pass (10 failures/761 runs); Open regressions: Component Readiness regression Linked bugs: None. The explicit Sippy Overlap assessment: The PR changes six API/feature-gate/CRD-manifest files to promote Missing-coverage risk: Low for the failed coverage. The job ran the full e2e suite and the failures are established outside-PR failures, while multiple independent e2e, upgrade, build, unit, and verification checks passed. The separate feature-promotion verification failure still requires its own resolution. Prior bot activity on this SHA: Rationale: The current revision is verified, the job is an eligible long-running e2e job, and tests ran. The exact job is only 25% successful across the recent PR fleet, five router failures have elevated global failure counts, the exact RouteExternalCertificate test has an open AWS/OVN/external Component Readiness regression, and the PR does not modify the tested implementations. These gates support overriding this one e2e context; the separate failed feature-promotion verification check remains blocking. If you disagree with this assessment, rerun the current job with AI-generated. Review for accuracy. |
|
@redhat-chai-bot: Overrode contexts on behalf of redhat-chai-bot: ci/prow/e2e-aws-ovn These overrides will persist across retests on the current HEAD SHA. Pushing a new commit will clear them. Use 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/verify-feature-promotion We agreed that these tests are pretty binary in their nature, components are either compliant or they are not. There's not enough data typically but all of the tests that have run, do pass. /lgtm |
|
@JoelSpeed: This PR has been marked as verified by 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. |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-feature-promotion 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. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: JoelSpeed The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@joelanford: 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. |
|
/jira backport release-5.0 |
|
@joelanford: The following backport issues have been created: Queuing cherrypicks to the requested branches to be created after this PR merges: 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. |
|
@openshift-ci-robot: #2883 failed to apply on top of branch "release-5.0": 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. |
Summary
Promotes the
TLSAdherencefeature gate to GA by enabling it in theDefaultandOKDfeature sets (in addition to the existingTechPreviewNoUpgradeandDevPreviewNoUpgrade).This enables the
tlsAdherencefield on theapiserver.config.openshift.io/v1APIServer resource for all clusters, allowing administrators to control how strictly components honor the centralized TLS security profile.References