-
Notifications
You must be signed in to change notification settings - Fork 565
TRT-2313: Revert "remove unused feature gate InsightsConfigAPI" #2495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
TRT-2313: Revert "remove unused feature gate InsightsConfigAPI" #2495
Conversation
@neisw: This pull request references TRT-2313 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 bug to target the "4.21.0" version, but no target version was set. In 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. |
Hello @neisw! Some important instructions when contributing to openshift/api: |
/payload-job periodic-ci-openshift-release-master-nightly-4.21-e2e-aws-ovn-upgrade-fips |
@neisw: 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/623e1830-9869-11f0-99c5-e0d3f75ef46a-0 |
[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.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@neisw Anything specifically pointing to this PR as being the culprit? Our tooling for feature gates is designed such that if any cluster component attempts to read a feature gate that doesn't exist, it panics. The linked failures don't show the It's quite possible that some component isn't following the correct pattern, but I'd like to understand where that is if there is something holding FGs wrong |
@JoelSpeed - suspicion at the moment is proximity to the operator failing and noting that the original pr did not pass a minor upgrade. I don't have absolute proof yet but wanted @opokornyy to have a look as well while running the payload job. |
/payload-job periodic-ci-openshift-release-master-ci-4.21-upgrade-from-stable-4.20-e2e-gcp-ovn-rt-upgrade |
@neisw: 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/b2fb0e90-9887-11f0-9c36-c55047959703-0 |
/hold |
Reverts #2474
Per OpenShift policy, we are reverting this breaking change to get CI and/or nightly payloads flowing again.
Payload failures beginning with 4.21.0-0.nightly-2025-09-22-183616 with failures like:
To unrevert this, revert this PR, and layer an additional separate commit on top that addresses the problem. Before merging the unrevert, please run these jobs on the PR and check the result of these jobs to confirm the fix has corrected the problem:
CC: @opokornyy