Skip to content

Conversation

@copejon
Copy link
Contributor

@copejon copejon commented Jan 23, 2026

No description provided.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 23, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jan 23, 2026
@openshift-ci-robot openshift-ci-robot added jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jan 23, 2026
@openshift-ci-robot
Copy link

@copejon: This pull request references Jira Issue OCPBUGS-73945, which is invalid:

  • expected the bug to target either version "4.22." or "openshift-4.22.", but it targets "4.21.z" instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

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.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 23, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: copejon

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 23, 2026
Copy link
Contributor Author

@copejon copejon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/jira refresh

@copejon copejon force-pushed the ocpbugs-73945 branch 2 times, most recently from 35dcb79 to 18ec209 Compare January 28, 2026 22:32
@copejon
Copy link
Contributor Author

copejon commented Jan 29, 2026

/jira refresh

@openshift-ci-robot openshift-ci-robot added jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. and removed jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. labels Jan 29, 2026
@openshift-ci-robot
Copy link

@copejon: This pull request references Jira Issue OCPBUGS-73945, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (4.22.0) matches configured target version for branch (4.22.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @jogeo

Details

In response to this:

/jira refresh

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 openshift-ci bot requested a review from jogeo January 29, 2026 17:09
@copejon copejon marked this pull request as ready for review February 5, 2026 15:04
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Feb 5, 2026
@openshift-ci openshift-ci bot requested review from ggiguash and pacevedom February 5, 2026 15:10
@copejon
Copy link
Contributor Author

copejon commented Feb 6, 2026

/test e2e-aws-tests
/test e2e-aws-tests-arm
/test verify

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Feb 6, 2026

@copejon: all tests passed!

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.

@ggiguash
Copy link
Contributor

@coderabbitai perform full review

@coderabbitai
Copy link

coderabbitai bot commented Feb 11, 2026

@ggiguash: I'll perform a full review of all the changes in this PR.

✅ Actions performed

Full review triggered.

@coderabbitai
Copy link

coderabbitai bot commented Feb 11, 2026

Walkthrough

The PR introduces a new feature gate specialHandlingSupportExceptionRequired to control which custom-enabled feature gates can proceed during upgrades. It refactors the feature gate lock management system by replacing the CustomNoUpgrade type with EnableDisableFeatures and adds validation logic to prevent upgrades when feature gates lack special handling support exceptions.

Changes

Cohort / File(s) Summary
Configuration Files
cmd/generate-config/config/config-openapi-spec.json, docs/user/howto_config.md, packaging/microshift/config.yaml
Added new specialHandlingSupportExceptionRequired field to feature gates schema and default configurations with enabled and disabled lists. Enhanced customNoUpgrade field with descriptive documentation.
Config Type Definitions
pkg/config/apiserver.go
Renamed CustomNoUpgrade struct to EnableDisableFeatures and updated FeatureGates.CustomNoUpgrade field type accordingly. Added new SpecialHandlingSupportExceptionRequired field of type EnableDisableFeatures to FeatureGates.
Feature Gate Lock Management
pkg/admin/prerun/featuregate_lock.go
Refactored feature gate lock management to accept *config.FeatureGates parameters instead of *config.Config. Updated lock file struct to use EnableDisableFeatures type. Added upgradeChecksPass() function with set-based comparison logic to detect version upgrades and identify custom-enabled gates lacking special handling exception support. Enhanced validation and error messaging.
Feature Gate Lock Tests
pkg/admin/prerun/featuregate_lock_test.go
Updated test data structures and test cases to use EnableDisableFeatures type for CustomNoUpgrade. Modified function call signatures to pass *config.FeatureGates pointers. Extended test matrix with new fields customNoUpgrade and specialHandlingSupportException in TestFeatureGateLockManagement_VersionChange.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

level=error msg="Running error: context loading failed: failed to load packages: failed to load packages: failed to load with go/packages: err: exit status 1: stderr: go: inconsistent vendoring in :\n\tgithub.com/apparentlymart/go-cidr@v1.1.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/coreos/go-systemd@v0.0.0-20190321100706-95778dfbb74e: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/google/go-cmp@v0.7.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/miekg/dns@v1.1.63: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/openshift/api@v0.0.0-20251117165054-348370f055bf: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/openshift/build-machinery-go@v0.0.0-20251023084048-5d77c1a5e5af: is explicitly required in go.mod, but not marked as explicit

... [truncated 28336 characters] ...

belet: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/metrics: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/mount-utils: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/pod-security-admission: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/sample-apiserver: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/sample-cli-plugin: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\tk8s.io/sample-controller: is replaced in go.mod, but not marked as replaced in vendor/modules.txt\n\n\tTo ignore the vendor directory, use -mod=readonly or -mod=mod.\n\tTo sync the vendor directory, run:\n\t\tgo mod vendor\n"


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.

❤️ Share

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
pkg/admin/prerun/featuregate_lock_test.go (1)

131-136: ⚠️ Potential issue | 🟡 Minor

Duplicate error check — the same err is checked and reported twice.

Lines 131–133 and 134–136 are identical.

Proposed fix
 			err := configValidationChecksPass(featureGateLockFile{
 				FeatureSet:      tt.fg.FeatureSet,
 				CustomNoUpgrade: tt.fg.CustomNoUpgrade,
 			}, &tt.fg)
 			if err != nil {
 				t.Errorf("featureValidationsPass() error = %v", err)
 			}
-			if err != nil {
-				t.Errorf("featureValidationsPass() error = %v", err)
-			}
pkg/config/apiserver.go (1)

142-157: ⚠️ Potential issue | 🟠 Major

Extend validateFeatureGates to validate SpecialHandlingSupportExceptionRequired.

The new SpecialHandlingSupportExceptionRequired field is not validated (lines 187–229). This allows invalid configurations such as:

  • Required feature gates listed in SpecialHandlingSupportExceptionRequired.Disabled
  • The same gate in both enabled and disabled lists within SpecialHandlingSupportExceptionRequired
  • Gates in SpecialHandlingSupportExceptionRequired that don't exist in CustomNoUpgrade (which has no effect and may confuse users)

Additionally, the GoString() method (lines 176–177) omits SpecialHandlingSupportExceptionRequired from its output, making debugging incomplete.

🤖 Fix all issues with AI agents
In `@pkg/admin/prerun/featuregate_lock_test.go`:
- Around line 455-467: The test case labeled "minor version upgrade with special
handling support exception should succeed" uses getVersion(1, -21, 0) which
yields a major version change instead of a minor bump; update the test to use
getVersion(0, 1, 0) so currentVer represents the intended minor upgrade (e.g.,
4.21.0 -> 4.22.0). Locate the table entry in featuregate_lock_test.go (the
struct with fields name, lockFileVer, currentVer, wantErr, description,
customNoUpgrade, specialHandlingSupportException) and replace the currentVer
value for that case from getVersion(1, -21, 0) to getVersion(0, 1, 0).
🧹 Nitpick comments (1)
pkg/admin/prerun/featuregate_lock.go (1)

131-136: Minor: variable assignment between error-producing call and its error check.

lockedVersion assignment on line 133 sits between the getExecutableVersion() call and the err check. While correct, this is unusual Go style and could be slightly confusing.

Proposed reorder
 func upgradeChecksPass(lockFile featureGateLockFile, fgCfg *config.FeatureGates) error {
 	currentExecutableVersion, err := getExecutableVersion()
-	lockedVersion := lockFile.Version
 	if err != nil {
 		return fmt.Errorf("failed to get current executable version: %w", err)
 	}
+	lockedVersion := lockFile.Version

Comment on lines +455 to 467
{
name: "minor version upgrade with special handling support exception should succeed",
lockFileVer: getVersion(0, 0, 0),
currentVer: getVersion(1, -21, 0),
wantErr: false,
description: "minor version upgrade (4.21.0 -> 4.22.0) with special handling support exception should succeed",
customNoUpgrade: &config.EnableDisableFeatures{
Enabled: []string{"FeatureA"},
},
specialHandlingSupportException: &config.EnableDisableFeatures{
Enabled: []string{"FeatureA"},
},
},
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

Test case uses wrong version: tests major upgrade instead of minor upgrade.

The test name and description say "minor version upgrade (4.21.0 -> 4.22.0)" but getVersion(1, -21, 0) produces {5, 0, 0}, which is a major version change — identical to the test case above at line 442. This should use getVersion(0, 1, 0) to test an actual minor version upgrade to 4.22.0.

Proposed fix
 		{
 			name:        "minor version upgrade with special handling support exception should succeed",
 			lockFileVer: getVersion(0, 0, 0),
-			currentVer:  getVersion(1, -21, 0),
+			currentVer:  getVersion(0, 1, 0),
 			wantErr:     false,
-			description: "minor version upgrade (4.21.0 -> 5.0.0) with special handling support exception should succeed",
+			description: "minor version upgrade (4.21.0 -> 4.22.0) with special handling support exception should succeed",
🤖 Prompt for AI Agents
In `@pkg/admin/prerun/featuregate_lock_test.go` around lines 455 - 467, The test
case labeled "minor version upgrade with special handling support exception
should succeed" uses getVersion(1, -21, 0) which yields a major version change
instead of a minor bump; update the test to use getVersion(0, 1, 0) so
currentVer represents the intended minor upgrade (e.g., 4.21.0 -> 4.22.0).
Locate the table entry in featuregate_lock_test.go (the struct with fields name,
lockFileVer, currentVer, wantErr, description, customNoUpgrade,
specialHandlingSupportException) and replace the currentVer value for that case
from getVersion(1, -21, 0) to getVersion(0, 1, 0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/severity-critical Referenced Jira bug's severity is critical for the branch this PR is targeting. jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants