CNTRLPLANE-2796: promote the event-ttl feature by tjungblu · Pull Request #2722 · openshift/api

tjungblu · 2026-02-24T06:51:18Z

This adds the event-ttl feature to the default feature set.

Introduction PR in #2520

Corresponding enhancement in
openshift/enhancements#1857

We’re seeking an exception for the automated FeatureGate verification on this promotion. While a functional e2e test has now merged and is reporting into the component readiness dashboard, we are only contributing this single test case to protect CI stability.

Changing the event-ttl causes unavoidable data loss for a period of time, which would negatively impact monitortests and other invariant testing that requires a full event history. To avoid compromising these other CI signals, we have focused on a 5-minute soak as our primary validator rather than expanding to the five-test requirement.

Furthermore, API boundaries are covered by unit tests in this repository. This is a mature upstream setting already running on large-scale clusters via support exceptions. Given this production track record, the merged CI coverage, and the risks additional tests pose to the broader suite, we believe this is ready for Default.

openshift-ci-robot · 2026-02-24T06:51:20Z

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

openshift-ci-robot · 2026-02-24T06:51:22Z

@tjungblu: This pull request references CNTRLPLANE-2796 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 "4.22.0" version, but no target version was set.

Details

In response to this:

This adds the event-ttl feature to the default feature set.

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 · 2026-02-24T06:51:22Z

Hello @tjungblu! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

coderabbitai · 2026-02-24T06:51:38Z

📝 Walkthrough

Walkthrough

The changes reorder and expand the features.md table, inserting a contiguous block of new rows and moving EventTTL. features/features.go updates multiple feature-gate enablement entries to include Default and OKD contexts in addition to existing TechPreview/DevPreview settings. Four FeatureGate manifest files (Hypershift and SelfManagedHA, Default and OKD) move EventTTL from the disabled to the enabled list. Several CRD manifest files defining the KubeAPIServer custom resource (multiple profile variants) are deleted, and one CRD file has a metadata annotation removed.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: promoting the event-ttl feature to the default feature set, which aligns with the changeset modifications across multiple feature gate files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The PR description clearly explains the objective: promoting the event-ttl feature to the default feature set, with supporting context about related PRs, enhancements, and CI considerations.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

openshift-ci · 2026-02-24T06:51:45Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign deads2k for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-ci-robot · 2026-02-24T06:53:20Z

@tjungblu: This pull request references CNTRLPLANE-2796 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 "4.22.0" version, but no target version was set.

Details

In response to this:

This adds the event-ttl feature to the default feature set.

Introduction PR in #2520

Corresponding enhancement in
openshift/enhancements#1857

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.

This adds the event-ttl feature to the default feature set. Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>

openshift-ci-robot · 2026-02-24T09:42:14Z

@tjungblu: This pull request references CNTRLPLANE-2796 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 "4.22.0" version, but no target version was set.

Details

In response to this:

This adds the event-ttl feature to the default feature set.

Introduction PR in #2520

Corresponding enhancement in
openshift/enhancements#1857

We’re seeking an exception for the automated FeatureGate verification on this promotion. While we have a functional e2e test, it’s currently blocked from merging into the operator repo (see #2009) due to the ongoing OTA migration, so we've landed it in the QE repo instead. Runs from those are not observed by Sippy.

Meeting the "five test" requirement isn't feasible here because each test case requires a long wait-time (N minutes) to verify the setting, making a larger suite too expensive for CI; we’ve focused on the 5-minute soak as our primary signal.
Furthermore, the API boundaries are already covered by unit tests in this repository and this is a mature upstream setting that several customers are already running on large-scale clusters via support exceptions.

Given the production track record and the QE-side coverage, we believe this is ready for Default despite the script flags.

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 · 2026-02-24T10:02:59Z

@tjungblu: This pull request references CNTRLPLANE-2796 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 "4.22.0" version, but no target version was set.

Details

In response to this:

This adds the event-ttl feature to the default feature set.

Introduction PR in #2520

Corresponding enhancement in
openshift/enhancements#1857

We’re seeking an exception for the automated FeatureGate verification on this promotion. While we have a functional e2e test, it’s currently blocked from merging into the operator repo (see #2009) due to the ongoing OTA migration, so we've landed it in the QE repo instead. Runs from those are not observed by Sippy.

Meeting the "five test" requirement isn't feasible here because each test case requires a long wait-time (N minutes) to verify the setting, making a larger suite too expensive for CI; we’ve focused on the 5-minute soak as our primary signal.
Furthermore, the API boundaries are already covered by unit tests in this repository and this is a mature upstream setting that several customers are already running on large-scale clusters via support exceptions.

Given the production track record and the QE-side coverage, we believe this is ready for Default.

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.

gangwgr · 2026-02-24T10:57:14Z

test run- ./cluster-kube-apiserver-operator-tests-ext run-test "[Jira:kube-apiserver][sig-api-machinery][```
FeatureGate:EventTTL] Event TTL Configuration should configure and validate eventTTLMinutes=5m [Timeout:60m][Operator][Serial]"
  Running Suite:  - /Users/rgangwar/Downloads/backupoffice/cluster-kube-apiserver-operator
  ========================================================================================
  Random Seed: 1771929143 - will randomize all specs

  Will run 1 of 1 specs
  ------------------------------
  [Jira:kube-apiserver][sig-api-machinery][FeatureGate:EventTTL] Event TTL Configuration should configure and validate eventTTLMinutes=5m [Timeout:60m][Operator][Serial] [Lifecycle:informing]
  github.com/openshift/cluster-kube-apiserver-operator/test/e2e/event_ttl.go:176
Found configuration for host https://api.rg-24b.qe.devcluster.openshift.com:6443.
    STEP: === Setup: Checking and enabling EventTTL feature gate === @ 02/24/26 16:02:23.061
    STEP:   Original FeatureSet: , Enabled features: 0 @ 02/24/26 16:02:24.501
    STEP: EventTTL feature gate is already enabled @ 02/24/26 16:02:24.501
    STEP: === Starting test for eventTTLMinutes=5 at 2026-02-24T16:02:24+05:30 === @ 02/24/26 16:02:24.501
    STEP: Current eventTTLMinutes: <not set> @ 02/24/26 16:02:25.347
    STEP: Step 1: Configuring eventTTLMinutes=5 in KubeAPIServer CR @ 02/24/26 16:02:25.347
    STEP:   Patch data: {"spec":{"eventTTLMinutes":5}} @ 02/24/26 16:02:25.347
    STEP: [OK] eventTTLMinutes=5 patch applied at 2026-02-24T16:02:26+05:30 @ 02/24/26 16:02:26.212
    STEP:   [VERIFIED] KubeAPIServer CR now has eventTTLMinutes=5 @ 02/24/26 16:02:26.68
    STEP: Step 2: Waiting for new revision to roll out (timeout: 20 minutes)... @ 02/24/26 16:02:26.68
    STEP:   Rollout started at: 2026-02-24T16:02:26+05:30 @ 02/24/26 16:02:26.68
    STEP:   Initial state: 3 pods, oldest created at 2026-02-24T15:34:05+05:30, initial revision: 6 @ 02/24/26 16:02:27.218
    STEP:   [Attempt 1] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:02:43.523
    STEP:   [Attempt 4] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:03:28.579
    STEP:   [Attempt 8] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:04:28.468
    STEP:   [Attempt 12] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:05:28.458
    STEP:   [Attempt 16] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:06:29.265
    STEP:   [Attempt 20] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:07:29.429
    STEP:   [Attempt 24] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:08:28.463
    STEP:   [Attempt 28] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:09:28.609
    STEP:   [Attempt 32] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:10:28.457
    STEP:   [Attempt 36] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:11:28.966
    STEP:   [Attempt 40] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:12:28.584
    STEP:   [Attempt 44] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:13:28.77
    STEP: [OK] New revision rolled out successfully in 11m46.819780625s @ 02/24/26 16:14:13.49
    STEP:   Configuration took: 11m48.152285292s total @ 02/24/26 16:14:13.49
    STEP: Step 3: Verifying event-ttl=5m in kube-apiserver config @ 02/24/26 16:14:13.49
    STEP: Checking event-ttl in pod config file @ 02/24/26 16:14:13.49
    STEP:   Checking config file in pod: kube-apiserver-ip-10-0-11-173.us-east-2.compute.internal @ 02/24/26 16:14:20.549
    STEP: Found event-ttl=5m in config.yaml @ 02/24/26 16:14:21.584
    STEP: [OK] eventTTLMinutes=5 verified in config file @ 02/24/26 16:14:21.584
    STEP: 
    Step 4: Validating that events actually expire after 5 minutes @ 02/24/26 16:14:21.585
    STEP:   Waiting 30 seconds for new TTL configuration to fully propagate... @ 02/24/26 16:14:21.585
    STEP: Creating test namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:51.585
    STEP: [OK] Test namespace created: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:52.014
    STEP: Creating NEW test event: apiload-event-1771929892 in namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:52.014
    STEP:   (This event should expire after the configured TTL, not the default 3h) @ 02/24/26 16:14:52.014
    STEP:   Event creation time: 2026-02-24T16:14:51+05:30 @ 02/24/26 16:14:52.014
    STEP: [OK] Event created at: 2026-02-24T16:14:52+05:30 @ 02/24/26 16:14:52.412
    STEP: [OK] Event confirmed to exist (UID: 6f36cc0f-6f4c-4fb4-951b-6b5c70427769) @ 02/24/26 16:14:52.806
    STEP:   Event CreationTimestamp: 2026-02-24T16:14:52+05:30 @ 02/24/26 16:14:52.806
    STEP:   This NEW event should expire after 5m (not the default 3h) @ 02/24/26 16:14:52.806
    STEP: Waiting 8 minutes for event to expire (expected expiration: 2026-02-24T16:22:52+05:30)... @ 02/24/26 16:14:52.807
    STEP:   ... 1/8 minutes elapsed @ 02/24/26 16:15:52.808
    STEP:   ... 2/8 minutes elapsed @ 02/24/26 16:16:52.807
    STEP:   ... 3/8 minutes elapsed @ 02/24/26 16:17:52.808
    STEP:   ... 4/8 minutes elapsed @ 02/24/26 16:18:52.808
    STEP:   ... 5/8 minutes elapsed @ 02/24/26 16:19:52.808
    STEP:   ... 6/8 minutes elapsed @ 02/24/26 16:20:52.808
    STEP:   ... 7/8 minutes elapsed @ 02/24/26 16:21:52.808
    STEP:   ... 8/8 minutes elapsed @ 02/24/26 16:22:52.808
    STEP: [OK] Event expired and deleted after approximately 8m0s @ 02/24/26 16:22:57.37
    STEP:   Expected TTL: 5m, Actual TTL: 8m0s @ 02/24/26 16:22:57.371
    STEP: 
    [SUCCESS] All steps completed successfully for eventTTLMinutes=5 @ 02/24/26 16:22:57.371
    STEP:   Total test duration: 20m32.87817825s @ 02/24/26 16:22:57.371
    STEP: Cleaning up test namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:22:57.371
    STEP: 
    Cleaning up eventTTLMinutes=5 configuration @ 02/24/26 16:22:57.805
    STEP:   Restoring eventTTLMinutes=null (was unset) @ 02/24/26 16:22:57.805
    STEP: eventTTLMinutes configuration restored @ 02/24/26 16:22:58.814
    STEP:   Skipping rollout wait (unsetting eventTTLMinutes may not trigger rollout) @ 02/24/26 16:22:58.814
  • [1240.766 seconds]
  ------------------------------

  Ran 1 of 1 Specs in 1240.766 seconds
  SUCCESS! -- 1 Passed | 0 Failed | 0 Pending | 0 Skipped
[
  {
    "name": "[Jira:kube-apiserver][sig-api-machinery][FeatureGate:EventTTL] Event TTL Configuration should configure and validate eventTTLMinutes=5m [Timeout:60m][Operator][Serial]",
    "lifecycle": "informing",
    "duration": 1240757,
    "startTime": "2026-02-24 10:32:23.058228 UTC",
    "endTime": "2026-02-24 10:53:03.815536 UTC",
    "result": "passed",
    "output": "  STEP: === Setup: Checking and enabling EventTTL feature gate === @ 02/24/26 16:02:23.061\n  STEP:   Original FeatureSet: , Enabled features: 0 @ 02/24/26 16:02:24.501\n  STEP: EventTTL feature gate is already enabled @ 02/24/26 16:02:24.501\n  STEP: === Starting test for eventTTLMinutes=5 at 2026-02-24T16:02:24+05:30 === @ 02/24/26 16:02:24.501\n  STEP: Current eventTTLMinutes: \u003cnot set\u003e @ 02/24/26 16:02:25.347\n  STEP: Step 1: Configuring eventTTLMinutes=5 in KubeAPIServer CR @ 02/24/26 16:02:25.347\n  STEP:   Patch data: {\"spec\":{\"eventTTLMinutes\":5}} @ 02/24/26 16:02:25.347\n  STEP: [OK] eventTTLMinutes=5 patch applied at 2026-02-24T16:02:26+05:30 @ 02/24/26 16:02:26.212\n  STEP:   [VERIFIED] KubeAPIServer CR now has eventTTLMinutes=5 @ 02/24/26 16:02:26.68\n  STEP: Step 2: Waiting for new revision to roll out (timeout: 20 minutes)... @ 02/24/26 16:02:26.68\n  STEP:   Rollout started at: 2026-02-24T16:02:26+05:30 @ 02/24/26 16:02:26.68\n  STEP:   Initial state: 3 pods, oldest created at 2026-02-24T15:34:05+05:30, initial revision: 6 @ 02/24/26 16:02:27.218\n  STEP:   [Attempt 1] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:02:43.523\n  STEP:   [Attempt 4] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:03:28.579\n  STEP:   [Attempt 8] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:04:28.468\n  STEP:   [Attempt 12] All 3 pods are running. New pods: 0/0. Revision: 6 @ 02/24/26 16:05:28.458\n  STEP:   [Attempt 16] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:06:29.265\n  STEP:   [Attempt 20] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:07:29.429\n  STEP:   [Attempt 24] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:08:28.463\n  STEP:   [Attempt 28] All 3 pods are running. New pods: 1/1. Revision: 7 @ 02/24/26 16:09:28.609\n  STEP:   [Attempt 32] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:10:28.457\n  STEP:   [Attempt 36] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:11:28.966\n  STEP:   [Attempt 40] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:12:28.584\n  STEP:   [Attempt 44] All 3 pods are running. New pods: 2/2. Revision: 7 @ 02/24/26 16:13:28.77\n  STEP: [OK] New revision rolled out successfully in 11m46.819780625s @ 02/24/26 16:14:13.49\n  STEP:   Configuration took: 11m48.152285292s total @ 02/24/26 16:14:13.49\n  STEP: Step 3: Verifying event-ttl=5m in kube-apiserver config @ 02/24/26 16:14:13.49\n  STEP: Checking event-ttl in pod config file @ 02/24/26 16:14:13.49\n  STEP:   Checking config file in pod: kube-apiserver-ip-10-0-11-173.us-east-2.compute.internal @ 02/24/26 16:14:20.549\n  STEP: Found event-ttl=5m in config.yaml @ 02/24/26 16:14:21.584\n  STEP: [OK] eventTTLMinutes=5 verified in config file @ 02/24/26 16:14:21.584\n  STEP: \n  Step 4: Validating that events actually expire after 5 minutes @ 02/24/26 16:14:21.585\n  STEP:   Waiting 30 seconds for new TTL configuration to fully propagate... @ 02/24/26 16:14:21.585\n  STEP: Creating test namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:51.585\n  STEP: [OK] Test namespace created: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:52.014\n  STEP: Creating NEW test event: apiload-event-1771929892 in namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:14:52.014\n  STEP:   (This event should expire after the configured TTL, not the default 3h) @ 02/24/26 16:14:52.014\n  STEP:   Event creation time: 2026-02-24T16:14:51+05:30 @ 02/24/26 16:14:52.014\n  STEP: [OK] Event created at: 2026-02-24T16:14:52+05:30 @ 02/24/26 16:14:52.412\n  STEP: [OK] Event confirmed to exist (UID: 6f36cc0f-6f4c-4fb4-951b-6b5c70427769) @ 02/24/26 16:14:52.806\n  STEP:   Event CreationTimestamp: 2026-02-24T16:14:52+05:30 @ 02/24/26 16:14:52.806\n  STEP:   This NEW event should expire after 5m (not the default 3h) @ 02/24/26 16:14:52.806\n  STEP: Waiting 8 minutes for event to expire (expected expiration: 2026-02-24T16:22:52+05:30)... @ 02/24/26 16:14:52.807\n  STEP:   ... 1/8 minutes elapsed @ 02/24/26 16:15:52.808\n  STEP:   ... 2/8 minutes elapsed @ 02/24/26 16:16:52.807\n  STEP:   ... 3/8 minutes elapsed @ 02/24/26 16:17:52.808\n  STEP:   ... 4/8 minutes elapsed @ 02/24/26 16:18:52.808\n  STEP:   ... 5/8 minutes elapsed @ 02/24/26 16:19:52.808\n  STEP:   ... 6/8 minutes elapsed @ 02/24/26 16:20:52.808\n  STEP:   ... 7/8 minutes elapsed @ 02/24/26 16:21:52.808\n  STEP:   ... 8/8 minutes elapsed @ 02/24/26 16:22:52.808\n  STEP: [OK] Event expired and deleted after approximately 8m0s @ 02/24/26 16:22:57.37\n  STEP:   Expected TTL: 5m, Actual TTL: 8m0s @ 02/24/26 16:22:57.371\n  STEP: \n  [SUCCESS] All steps completed successfully for eventTTLMinutes=5 @ 02/24/26 16:22:57.371\n  STEP:   Total test duration: 20m32.87817825s @ 02/24/26 16:22:57.371\n  STEP: Cleaning up test namespace: event-ttl-test-5m-1771929891 @ 02/24/26 16:22:57.371\n  STEP: \n  Cleaning up eventTTLMinutes=5 configuration @ 02/24/26 16:22:57.805\n  STEP:   Restoring eventTTLMinutes=null (was unset) @ 02/24/26 16:22:57.805\n  STEP: eventTTLMinutes configuration restored @ 02/24/26 16:22:58.814\n  STEP:   Skipping rollout wait (unsetting eventTTLMinutes may not trigger rollout) @ 02/24/26 16:22:58.814\n"
  }

everettraven · 2026-02-24T14:34:14Z

While we have a functional e2e test, it’s currently blocked from merging into the operator repo (see openshift/cluster-kube-apiserver-operator#2009) due to the ongoing OTA migration, so we've landed it in the QE repo instead. Runs from those are not observed by Sippy.

What about the OTA migration prevents these tests from being implemented?

Meeting the "five test" requirement isn't feasible here because each test case requires a long wait-time (N minutes) to verify the setting, making a larger suite too expensive for CI; we’ve focused on the 5-minute soak as our primary signal.
Furthermore, the API boundaries are already covered by unit tests in this repository and this is a mature upstream setting that several customers are already running on large-scale clusters via support exceptions.

If we can't reasonably get to five tests (i.e it doesn't make sense to have five tests) we can override that requirement, but that is generally few and far between. If you are confident that less than five tests is comprehensive enough coverage for this feature, an override seems fine on that requirement.

If existing suites and/or jobs are not suitable for running these tests, it should be possible to create a new suite/job that is run to execute your tests in a more appropriate environment.

Given the production track record and the QE-side coverage, we believe this is ready for Default.

QE-side coverage is no longer sufficient for feature promotion. If you strongly believe your feature is an exception, you'll need to file an SBAR for the feature promotion and include a plan for how you are going to catch regressions to the feature until automated regression tests that report into component readiness are added.

openshift-ci-robot · 2026-03-09T14:06:21Z

@tjungblu: This pull request references CNTRLPLANE-2796 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 "4.22.0" version, but no target version was set.

Details

In response to this:

This adds the event-ttl feature to the default feature set.

Introduction PR in #2520

Corresponding enhancement in
openshift/enhancements#1857

We’re seeking an exception for the automated FeatureGate verification on this promotion. While a functional e2e test has now merged and is reporting into the component readiness dashboard, we are only contributing this single test case to protect CI stability.

Changing the event-ttl causes unavoidable data loss for a period of time, which would negatively impact monitortests and other invariant testing that requires a full event history. To avoid compromising these other CI signals, we have focused on a 5-minute soak as our primary validator rather than expanding to the five-test requirement.

Furthermore, API boundaries are covered by unit tests in this repository. This is a mature upstream setting already running on large-scale clusters via support exceptions. Given this production track record, the merged CI coverage, and the risks additional tests pose to the broader suite, we believe this is ready for Default.

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.

tjungblu · 2026-03-09T14:06:24Z

/retest-required

openshift-ci · 2026-03-09T14:16:38Z

@tjungblu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/verify-feature-promotion	`73f6501`	link	true	`/test verify-feature-promotion`

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Feb 24, 2026

openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 24, 2026

openshift-ci bot requested review from JoelSpeed and everettraven February 24, 2026 06:51

CNTRLPLANE-2796: promote the event-ttl feature

73f6501

This adds the event-ttl feature to the default feature set. Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>

tjungblu force-pushed the CNTRLPLANE-2796 branch from ebfc3fe to 73f6501 Compare February 24, 2026 09:15

openshift-ci bot added size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Feb 24, 2026

Conversation

tjungblu commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 24, 2026

Uh oh!

openshift-ci-robot commented Feb 24, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci bot commented Feb 24, 2026

Uh oh!

coderabbitai bot commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Uh oh!

openshift-ci bot commented Feb 24, 2026

Uh oh!

openshift-ci-robot commented Feb 24, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 24, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Feb 24, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gangwgr commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

everettraven commented Feb 24, 2026

Uh oh!

openshift-ci-robot commented Mar 9, 2026 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tjungblu commented Mar 9, 2026

Uh oh!

openshift-ci bot commented Mar 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

tjungblu commented Feb 24, 2026 •

edited

Loading

openshift-ci-robot commented Feb 24, 2026 •

edited by openshift-ci bot

Loading

coderabbitai bot commented Feb 24, 2026 •

edited

Loading

openshift-ci-robot commented Feb 24, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Feb 24, 2026 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Feb 24, 2026 •

edited by openshift-ci bot

Loading

gangwgr commented Feb 24, 2026 •

edited

Loading

openshift-ci-robot commented Mar 9, 2026 •

edited by openshift-ci bot

Loading