Skip to content

OCPBUGS-64688: use ObservedGeneration to determine Progressing status#1169

Open
sg00dwin wants to merge 3 commits into
openshift:mainfrom
sg00dwin:OCPBUGS-64688-progressing-true-during-node-reboot
Open

OCPBUGS-64688: use ObservedGeneration to determine Progressing status#1169
sg00dwin wants to merge 3 commits into
openshift:mainfrom
sg00dwin:OCPBUGS-64688-progressing-true-during-node-reboot

Conversation

@sg00dwin
Copy link
Copy Markdown
Member

@sg00dwin sg00dwin commented May 29, 2026

Summary

  • Replace IsAvailableAndUpdated with ObservedGeneration < Generation check for the Progressing condition
  • IsAvailableAndUpdated used UpdatedReplicas == Replicas, which falsely triggers during node reboots when pods are temporarily disrupted — even though the operator made no spec changes
  • ObservedGeneration < Generation only fires when the operator has updated the deployment spec and the deployment controller hasn't processed it yet
  • Extract checkDeploymentGenerationProgress helper for testability and add unit tests

Root Cause

During node reboots (MCO draining nodes), console pods are terminated and replacements are created. During the ~30-second gap, UpdatedReplicas != Replicas, causing IsAvailableAndUpdated to return false and the operator to report Progressing=True. The operator made no changes — the disruption is external.

Why This Fix

ObservedGeneration < Generation precisely detects operator-initiated spec changes:

  • Node reboot (no spec change): Generation unchanged → Progressing=False ✓
  • Real upgrade (operator updates spec): Generation bumps → Progressing=True ✓
  • Fresh install: Generation=1, ObservedGeneration=0 → Progressing=True ✓

The Available condition (IsAvailable at line 231) independently monitors pod readiness and is unaffected.

Test plan

  • make builds successfully
  • make test-unit all tests pass
  • gofmt / go vet clean
  • Unit tests for checkDeploymentGenerationProgress: ObservedGeneration equal, less than, greater than Generation, both zero, and initial rollout
  • Manual verification on live OCP 4.22 cluster (node drain stays Progressing=False, spec change triggers Progressing=True)
  • CI e2e upgrade test [Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should stay Progressing=False while MCO is Progressing=True should stop failing (~8% failure rate on Sippy currently)

Assisted-by: Claude Code (Opus 4.6)

Summary by CodeRabbit

  • Bug Fixes

    • Improved deployment rollout status reporting: the operator now marks a deployment as "progressing" based on whether the cluster has observed the latest deployment generation, avoiding unstable signals from fluctuating replica counts during external disruptions and giving more reliable rollout/version-change status.
  • Tests

    • Added tests covering observed-generation scenarios (equal, less-than, greater-than, and initial rollout) to ensure consistent and correct progression reporting.

@openshift-ci-robot openshift-ci-robot added 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 May 29, 2026
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@sg00dwin: This pull request references Jira Issue OCPBUGS-64688, which is invalid:

  • expected the bug to target either version "5.0." or "openshift-5.0.", 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:

Summary

  • Replace IsAvailableAndUpdated with ObservedGeneration < Generation check for the Progressing condition
  • IsAvailableAndUpdated used UpdatedReplicas == Replicas, which falsely triggers during node reboots when pods are temporarily disrupted — even though the operator made no spec changes
  • ObservedGeneration < Generation only fires when the operator has updated the deployment spec and the deployment controller hasn't processed it yet

Root Cause

During node reboots (MCO draining nodes), console pods are terminated and replacements are created. During the ~30-second gap, UpdatedReplicas != Replicas, causing IsAvailableAndUpdated to return false and the operator to report Progressing=True. The operator made no changes — the disruption is external.

Why This Fix

ObservedGeneration < Generation precisely detects operator-initiated spec changes:

  • Node reboot (no spec change): Generation unchanged → Progressing=False ✓
  • Real upgrade (operator updates spec): Generation bumps → Progressing=True ✓
  • Fresh install: Generation=1, ObservedGeneration=0 → Progressing=True ✓

The Available condition (IsAvailable at line 231) independently monitors pod readiness and is unaffected.

Test plan

  • make builds successfully
  • make test-unit all tests pass
  • gofmt / go vet clean
  • CI e2e upgrade test [Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should stay Progressing=False while MCO is Progressing=True should stop failing (~8% failure rate on Sippy currently)

Assisted-by: Claude Code (Opus 4.6)

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.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 29, 2026

Walkthrough

The change modifies SyncLoopRefresh to treat a Deployment as "Progressing" when its Status.ObservedGeneration is less than Generation by calling a new helper; tests were added to validate behavior across generation/observedGeneration combinations.

Changes

Deployment Generation Observation Check

Layer / File(s) Summary
Generation observation enforcement
pkg/console/operator/sync_v400.go
SyncLoopRefresh now calls checkDeploymentGenerationProgress(actualDeployment) and returns an error when actualDeployment.Status.ObservedGeneration < actualDeployment.Generation, replacing the prior IsAvailableAndUpdated-based progressing path.
Generation check helper
pkg/console/operator/sync_v400.go
Added checkDeploymentGenerationProgress(deployment *appsv1.Deployment) error which returns an error when ObservedGeneration < Generation and nil otherwise.
Test imports update
pkg/console/operator/sync_v400_test.go
Updated imports to include k8s.io/api/apps/v1 (aliased as appsv1) for constructing Deployment objects in tests.
Deployment progressing tests
pkg/console/operator/sync_v400_test.go
Added TestDeploymentProgressingByGeneration, a table-driven test asserting error/no-error and exact error messages for various Generation/ObservedGeneration cases.

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (14 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: replacing IsAvailableAndUpdated with ObservedGeneration-based check for the Progressing condition.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed All 5 test cases use stable, descriptive static names free of dynamic information like generated identifiers, timestamps, or variable values.
Test Structure And Quality ✅ Passed Repository uses standard Go testing, not Ginkgo, making custom check inapplicable. Test follows codebase conventions with clear assertions and single-responsibility test cases.
Microshift Test Compatibility ✅ Passed No Ginkgo e2e tests added. Only standard Go unit test (TestDeploymentProgressingByGeneration) was added, which uses Kubernetes Deployment API available on MicroShift.
Single Node Openshift (Sno) Test Compatibility ✅ Passed No Ginkgo e2e tests were added. The test file pkg/console/operator/sync_v400_test.go contains only standard Go unit tests using testing.T, not Ginkgo framework tests. The check is not applicable.
Topology-Aware Scheduling Compatibility ✅ Passed PR changes only status logic, not scheduling. Existing deployment constraints already topology-aware via ControlPlaneTopology checks.
Ote Binary Stdout Contract ✅ Passed Not an OTE binary - this is console-operator code. Modified files are standard operator package logic and unit tests with no stdout writes in process-level code.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed PR adds only standard Go unit tests (TestDeploymentProgressingByGeneration), not Ginkgo e2e tests. Check targets Ginkgo e2e tests only; unit tests are not in scope.
No-Weak-Crypto ✅ Passed No weak crypto, custom crypto implementations, or non-constant-time secret comparisons found. Code only compares Kubernetes Deployment metadata integer fields.
Container-Privileges ✅ Passed PR modifies only Go source code, not Kubernetes manifests. No container privilege configurations are added or modified in this PR.
No-Sensitive-Data-In-Logs ✅ Passed No sensitive data in logs. New error messages only contain deployment generation counters (numeric Kubernetes metadata), not passwords, tokens, API keys, PII, or other sensitive information.
Description check ✅ Passed The PR description comprehensively covers all required template sections with detailed analysis, solution explanation, and test plan verification.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

@openshift-ci openshift-ci Bot requested review from TheRealJon and spadgett May 29, 2026 13:46
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented May 29, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: sg00dwin
Once this PR has been reviewed and has the lgtm label, please assign therealjon 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:

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

@sg00dwin
Copy link
Copy Markdown
Member Author

/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 May 29, 2026
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@sg00dwin: This pull request references Jira Issue OCPBUGS-64688, 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 (5.0.0) matches configured target version for branch (5.0.0)
  • bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)
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.

@sg00dwin
Copy link
Copy Markdown
Member Author

/retest-required

@Leo6Leo
Copy link
Copy Markdown
Contributor

Leo6Leo commented May 29, 2026

/cc @Leo6Leo

Spinning cluster to do QE currently

@openshift-ci openshift-ci Bot requested a review from Leo6Leo May 29, 2026 18:04
@Leo6Leo
Copy link
Copy Markdown
Contributor

Leo6Leo commented May 29, 2026

Manual Verification

Deployed the PR build to a live OCP 4.22 cluster (3 control-plane nodes, Azure).

Node drain (should stay Progressing=False): Drained a node hosting a console pod. Pod was evicted and rescheduled. Progressing stayed False throughout — lastTransitionTime never changed.

Spec change (should trigger Progressing=True): Changed logLevel to TraceAll, bumping deployment generation 3→4. Progressing correctly flipped to True ("deployment generation 4 not yet observed (current: 3)"), then resolved to False 2s later.

Both scenarios behave as expected.

Currently just waiting for the CI to past before I give the verify label.

Comment thread pkg/console/operator/sync_v400.go Outdated
// counts — they fluctuate during external disruptions (node reboots)
// that the operator did not cause. See https://issues.redhat.com/browse/OCPBUGS-64688
if actualDeployment.Status.ObservedGeneration < actualDeployment.Generation {
return fmt.Errorf("deployment generation %d not yet observed (current: %d)",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The parenthetical says "current" but passes ObservedGeneration. Consider changing the wording to make it more accurate:

Suggested change
return fmt.Errorf("deployment generation %d not yet observed (current: %d)",
return fmt.Errorf("deployment generation %d not yet observed (observed: %d)",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@sg00dwin Could you add some unit tests for the new behavior?

The old IsAvailableAndUpdated at least had its own unit tests in deployment_test.go. The new inline comparison ObservedGeneration < Generation has no test coverage. A table-driven test with cases like: - ObservedGeneration == Generation → no error (not progressing) - ObservedGeneration < Generation → returns error (progressing) - ObservedGeneration > Generation → no error (edge case, already processed)

would help prevent regressions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd also be considering adding an e2e to one of the upgrade jobs? If we can write one that isn't a giant pain.

Copy link
Copy Markdown
Member Author

@sg00dwin sg00dwin Jun 2, 2026

Choose a reason for hiding this comment

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

Unit tests: Added table-driven unit tests for the ObservedGeneration-based Progressing check covering: equal, less than, greater than, both zero, and initial rollout scenarios.

Regarding e2e test: Good idea. There's already a story tracking this under the same epic: CONSOLE-5188 (e2e testing automation). It's currently unassigned and empty description. Added this suggestion for adding a console-owned e2e assertion to one of the upgrade jobs.

- Fix error message wording: "current" → "observed" to accurately describe the ObservedGeneration value being reported
- Add table-driven unit tests for the ObservedGeneration-based Progressing check covering: equal, less than, greater than, both zero, and initial rollout scenarios

Assisted by: Claude (Opus 4.6)
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@sg00dwin: This pull request references Jira Issue OCPBUGS-64688, which is valid.

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

In response to this:

Summary

  • Replace IsAvailableAndUpdated with ObservedGeneration < Generation check for the Progressing condition
  • IsAvailableAndUpdated used UpdatedReplicas == Replicas, which falsely triggers during node reboots when pods are temporarily disrupted — even though the operator made no spec changes
  • ObservedGeneration < Generation only fires when the operator has updated the deployment spec and the deployment controller hasn't processed it yet

Root Cause

During node reboots (MCO draining nodes), console pods are terminated and replacements are created. During the ~30-second gap, UpdatedReplicas != Replicas, causing IsAvailableAndUpdated to return false and the operator to report Progressing=True. The operator made no changes — the disruption is external.

Why This Fix

ObservedGeneration < Generation precisely detects operator-initiated spec changes:

  • Node reboot (no spec change): Generation unchanged → Progressing=False ✓
  • Real upgrade (operator updates spec): Generation bumps → Progressing=True ✓
  • Fresh install: Generation=1, ObservedGeneration=0 → Progressing=True ✓

The Available condition (IsAvailable at line 231) independently monitors pod readiness and is unaffected.

Test plan

  • make builds successfully
  • make test-unit all tests pass
  • gofmt / go vet clean
  • CI e2e upgrade test [Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should stay Progressing=False while MCO is Progressing=True should stop failing (~8% failure rate on Sippy currently)

Assisted-by: Claude Code (Opus 4.6)

Summary by CodeRabbit

  • Bug Fixes

  • More accurate deployment rollout status: the operator now treats a deployment as "progressing" when the deployment's observed generation indicates the rollout isn't up-to-date, improving rollout/version-change reporting.

  • Tests

  • Added tests validating deployment progression behavior across observed-generation scenarios to ensure consistent status reporting.

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.

Copy link
Copy Markdown

@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: 2

🧹 Nitpick comments (1)
pkg/console/operator/sync_v400_test.go (1)

243-247: 💤 Low value

Consider whether this test case is necessary.

The case where ObservedGeneration > Generation should never occur in a real Kubernetes deployment—the controller sets ObservedGeneration to Generation when it processes a spec change, maintaining the invariant ObservedGeneration ≤ Generation. Testing this scenario adds coverage for an impossible state.

If this is intentional defensive coding against malformed data, consider adding a comment explaining the rationale. Otherwise, this test case could be removed to keep the test focused on realistic scenarios.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pkg/console/operator/sync_v400_test.go` around lines 243 - 247, The test case
named "ObservedGeneration greater than Generation: not progressing" covers an
impossible Kubernetes state (ObservedGeneration > Generation); either remove
this test to keep tests realistic or, if you intentionally want defensive
coverage, add a short comment above the test case explaining that this is
defensive testing against malformed/external data and why it's kept (referencing
the test case name and the table entry with generation: 2 and
observedGeneration: 3 in sync_v400_test.go) so future readers understand the
rationale.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@pkg/console/operator/sync_v400_test.go`:
- Around line 274-279: The test duplicates the ObservedGeneration check instead
of exercising the production logic; update tests to call the real check by
either (A) invoking the sync function in sync_v400.go that performs the
ObservedGeneration validation (so the test fails if that logic or error message
changes), or (B) extract the ObservedGeneration validation into a shared helper
(e.g., a new function like validateObservedGeneration or checkObservedGeneration
that takes the deployment and returns the same error) and use that helper from
both the production code in sync_v400.go and from this test; ensure the test
asserts the helper/sync function's returned error message rather than
reimplementing the fmt.Errorf logic and keep references to deployment.Generation
and deployment.Status.ObservedGeneration.
- Around line 3-12: Reorder the import block so it follows the standard groups:
keep standard library imports (fmt, testing) first, third-party imports
(github.com/go-test/deep) next, then Kubernetes/OpenShift imports (appsv1, v1,
metav1), and place the internal import
github.com/openshift/console-operator/pkg/api after the kube imports; update the
import grouping comments if present and ensure the import order matches the
documented convention referenced in the review.

---

Nitpick comments:
In `@pkg/console/operator/sync_v400_test.go`:
- Around line 243-247: The test case named "ObservedGeneration greater than
Generation: not progressing" covers an impossible Kubernetes state
(ObservedGeneration > Generation); either remove this test to keep tests
realistic or, if you intentionally want defensive coverage, add a short comment
above the test case explaining that this is defensive testing against
malformed/external data and why it's kept (referencing the test case name and
the table entry with generation: 2 and observedGeneration: 3 in
sync_v400_test.go) so future readers understand the rationale.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 17d399a0-d433-4f7a-879b-ec40a158724a

📥 Commits

Reviewing files that changed from the base of the PR and between e6d0bb7 and 1f1782f.

📒 Files selected for processing (2)
  • pkg/console/operator/sync_v400.go
  • pkg/console/operator/sync_v400_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • pkg/console/operator/sync_v400.go
📜 Review details
🧰 Additional context used
📓 Path-based instructions (7)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Follow Go coding standards and patterns documented in CONVENTIONS.md
Organize imports according to conventions documented in CONVENTIONS.md
Use gofmt to format Go code with standard formatting
Run go vet checks on all Go packages

Follow Go coding standards and patterns as documented in CONVENTIONS.md, including proper import organization

Organize Go code following the repository structure: main entry point in cmd/console/main.go, API constants in pkg/api/, operator command setup in pkg/cmd/operator/, and version command in pkg/cmd/version/

**/*.go: Use gofmt for formatting Go code
Follow standard Go naming conventions
Group imports in order: standard lib, 3rd party, kube/openshift, internal (marked with comments)
Use meaningful error messages with context in Go code
Set status conditions using status.Handle* functions with type prefixes (*Degraded, *Progressing, *Available, *Upgradeable)
Use typed errors and wrap errors to preserve stack context

OpenShift Tests Extension (OTE) binaries communicate with openshift-tests via JSON on stdout. Flag non-JSON stdout from the main binary process in process-level code: main(), init(), TestMain(), BeforeSuite(), AfterSuite(), SynchronizedBeforeSuite(), RunSpecs() setup, or top-level var/const initializers. Common violations include klog writing to stdout (must redirect to stderr), fmt.Print/Println/Printf in main or suite setup, and Ginkgo v2 suite configuration emitting warnings to stdout

Files:

  • pkg/console/operator/sync_v400_test.go

⚙️ CodeRabbit configuration file

**/*.go: Review Go code following OpenShift operator patterns.
See CONVENTIONS.md for coding standards and patterns.

Refer to the following skills based on CODE PATTERNS, not just file paths:

Refer to /controller-review when code contains:

  • Controller struct types (e.g., type *Controller struct)
  • func New*Controller( factory functions
  • factory.New().WithFilteredEventsInformers( pattern
  • .ToController( method calls
  • Sync(ctx context.Context, controllerContext factory.SyncContext) methods
  • operatorConfig.Spec.ManagementState checks
  • status.NewStatusHandler or status.Handle* functions

Refer to /sync-handler-review when code contains:

  • Main operator sync functions (e.g., sync_v400.go content)
  • Sequential resource syncing with early returns
  • Incremental reconciliation loops
  • Multiple resourceapply.Apply*() calls in sequence
  • Dependency ordering of ConfigMaps → Secrets → Service Accounts → RBAC → Services → Deployments → Routes
  • Feature gate conditional logic

Refer to /go-quality-review for all Go code to check:

  • Deprecated imports: ioutil.ReadFile, ioutil.WriteFile, ioutil.ReadAll
  • Deprecated patterns: Dial without DialContext
  • Error handling: missing %w in fmt.Errorf
  • Code smells: deep nesting (4+ levels), functions >100 lines
  • Magic values: unexplained numbers/strings
  • Context propagation: context.Background() instead of passed ctx
  • Missing godoc on exported functions

Files:

  • pkg/console/operator/sync_v400_test.go
**/*_test.go

📄 CodeRabbit inference engine (AGENTS.md)

Follow testing patterns and commands documented in TESTING.md

Follow testing patterns and commands as documented in TESTING.md, including running unit tests with 'make test-unit' and checks with 'make check'

**/*_test.go: Use table-driven tests for comprehensive coverage
Use httptest for HTTP handler testing in Go
Include proper cleanup functions in tests
Test both success and failure paths

Files:

  • pkg/console/operator/sync_v400_test.go

⚙️ CodeRabbit configuration file

**/*_test.go: Review test code for quality and patterns.

Refer to /unit-test-review when test is in pkg//*_test.go:**

  • Table-driven test structure with test cases
  • Use of go-test/deep for struct comparisons
  • Test naming conventions (TestFunctionName)
  • Error handling with wantErr pattern
  • Edge case coverage (nil, empty, boundary values)
  • Proper assertions with helpful error messages
  • Test isolation (no shared mutable state)

Refer to /e2e-test-review when test contains:

  • framework.MustNewClientset(t, nil) or similar e2e framework usage
  • wait.Poll or wait.PollImmediate patterns
  • retry.RetryOnConflict for updates
  • Cleanup via defer functions
  • Console/operator CR manipulations
  • Test assertions on cluster state

Suggest to use /e2e-test-review when:

  • PR adds new feature requiring e2e coverage
  • Test file is empty or skeleton
  • Comments indicate "TODO: add test"

Review for common issues:

  • Missing cleanup (defer statements)
  • Using time.Sleep instead of wait.Poll
  • Missing context timeouts
  • Vague error messages in assertions
  • Tests without table-driven structure when testing multiple cases
  • Ignoring errors with _
  • Tests without assertions

Files:

  • pkg/console/operator/sync_v400_test.go
{pkg,cmd}/**/*.go

📄 CodeRabbit inference engine (CLAUDE.md)

Use gofmt for code formatting on pkg and cmd directories

{pkg,cmd}/**/*.go: Format code using gofmt -w ./pkg ./cmd
Run go vet checks on all Go packages in ./pkg and ./cmd

Files:

  • pkg/console/operator/sync_v400_test.go
**/*sync*.go

📄 CodeRabbit inference engine (CONVENTIONS.md)

Implement sync loops (sync_v400) incrementally: start from zero, create/update missing requirements, and return to continue on next loop

Files:

  • pkg/console/operator/sync_v400_test.go
**/*.{go,java,py,js,ts,jsx,tsx,cs,cpp,c,rb,php}

📄 CodeRabbit inference engine (Custom checks)

**/*.{go,java,py,js,ts,jsx,tsx,cs,cpp,c,rb,php}: Flag logging that may expose passwords, tokens, API keys, PII (email, SSN, credit card), session IDs, internal hostnames, or customer data
Flag MD5, SHA1, DES, RC4, 3DES, Blowfish, ECB mode usage. Flag custom crypto implementations. Flag non-constant-time comparison of secrets or tokens

Files:

  • pkg/console/operator/sync_v400_test.go
**/{deploy,config,operator,controllers}/**/*.{yaml,yml,go}

📄 CodeRabbit inference engine (Custom checks)

**/{deploy,config,operator,controllers}/**/*.{yaml,yml,go}: When deployment manifests, operator code, or controllers are added or modified, check for scheduling constraints that assume a standard HA topology without topology-awareness. Flag required pod anti-affinity (requiredDuringSchedulingIgnoredDuringExecution with topologyKey: kubernetes.io/hostname) that breaks on SNO, TNF with replicas > 2, and TNA
When deployment manifests, operator code, or controllers are added or modified, check for pod topology spread constraints with whenUnsatisfiable: DoNotSchedule and hostname topology key that breaks on SNO and is problematic when maxSkew exceeds the number of schedulable nodes on TNF and TNA
When deployment manifests, operator code, or controllers are added or modified, check for replica count derived from node count without considering SNO, TNF, and TNA topology variations where fewer than 3 control-plane nodes exist, and TNA's arbiter node should not run general workloads
When deployment manifests, operator code, or controllers are added or modified, check for nodeSelector or node affinity targeting control-plane nodes (node-role.kubernetes.io/master or node-role.kubernetes.io/control-plane) that will fail on HyperShift where no nodes carry these labels
When deployment manifests, operator code, or controllers are added or modified, check for scheduling workloads to all control-plane nodes equally without excluding arbiter nodes. Flag broad or wildcard tolerations that inadvertently schedule to resource-constrained arbiter nodes on TNA clusters
When deployment manifests, operator code, or controllers are added or modified, check for assumptions that dedicated worker nodes exist. Code targeting only worker nodes via node-role.kubernetes.io/worker nodeSelector may need to also consider nodes that carry both control-plane and worker roles on SNO and TNF
When deployment manifests, operator code, or controllers are added or modified, check PodDisruptionBudgets designe...

Files:

  • pkg/console/operator/sync_v400_test.go
**/*.{py,js,ts,go,rs,java,rb,php,kt,swift,cs}

⚙️ CodeRabbit configuration file

**/*.{py,js,ts,go,rs,java,rb,php,kt,swift,cs}: Injection prevention (prodsec-skills):

  • SQL: parameterized queries only; no string concatenation
  • Command: no shell=True, os.system, or backtick exec with user input
  • LDAP/XPath: escape special characters in filters
  • Path traversal: canonicalize paths, reject ../
  • Deserialization: no pickle/yaml.load()/eval on untrusted data
  • Prototype pollution: no recursive merge of untrusted objects
  • Validate at trust boundaries with allow-lists, not deny-lists
  • Normalize Unicode and anchor regexes (^$); watch for ReDoS

Files:

  • pkg/console/operator/sync_v400_test.go

Comment thread pkg/console/operator/sync_v400_test.go
Comment thread pkg/console/operator/sync_v400_test.go Outdated
  - Fix error message wording: "current" → "observed"
  - Extract checkDeploymentGenerationProgress helper for testability
  - Add unit tests for ObservedGeneration-based Progressing check
  - Fix import ordering per project conventions

Assisted by: Claude (Opus 4.6)
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Jun 2, 2026

@sg00dwin: 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.

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

Labels

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.

4 participants