OCPBUGS-99943: set API-server-defaulted fields on deployment specs to prevent excessive update events - #1201
Conversation
… prevent pathological update events ApplyDeploymentWithForce replaces the entire deployment spec on every metadata-triggered update. Fields omitted from the operator's desired spec (progressDeadlineSeconds, revisionHistoryLimit, dnsPolicy, serviceAccount) were written as null, forcing the API server to re-default them on each write. This doubled the deployment update event count per legitimate trigger (e.g., plugin registration), exceeding the pathological event threshold in TechPreview CI jobs. Set these fields explicitly in both deployment YAML templates to match the API server defaults. Also set MaxSurge/MaxUnavailable on non-HA rolling update strategy for the same reason. Update test expectations to match. Assisted by: Claude Code (Opus 4.6)
openshift-ci-robot
added
jira/valid-reference
|
@sg00dwin: This pull request references Jira Issue OCPBUGS-99943, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. 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. |
WalkthroughDeployment manifests and generated deployment logic now specify rollout timing, revision history, service accounts, DNS policy, and non-HA rolling update percentages. Deployment tests update expected console and downloads specifications accordingly. ChangesDeployment defaults
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/jira refresh |
openshift-ci-robot
added
the
jira/valid-bug
|
@sg00dwin: This pull request references Jira Issue OCPBUGS-99943, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
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
removed
the
jira/invalid-bug
|
@sg00dwin: This pull request references Jira Issue OCPBUGS-99943, which is valid. 3 validation(s) were run on this bug
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. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: sg00dwin The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
sg00dwin
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pkg/console/subresource/deployment/deployment.go (1)
185-188: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCentralize the non-HA rollout percentage.
The same
"25%"magic string is duplicated across production and test code. Define a package-level constant and reuse it at every site:
pkg/console/subresource/deployment/deployment.go#L185-L188: use the named constant forMaxSurgeandMaxUnavailable.pkg/console/subresource/deployment/deployment_test.go#L430-L431: use the named constant in the console expectation.pkg/console/subresource/deployment/deployment_test.go#L1534-L1535: use the named constant inTestWithStrategy.pkg/console/subresource/deployment/deployment_test.go#L1875-L1876: use the named constant in the downloads expectation.As per coding guidelines, replace magic numbers and strings in Go code with named constants.
🤖 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/subresource/deployment/deployment.go` around lines 185 - 188, Define a package-level constant for the non-HA rollout percentage and update the RollingUpdateDeployment values in pkg/console/subresource/deployment/deployment.go#L185-L188 to reuse it for MaxSurge and MaxUnavailable. Replace the duplicated "25%" literals at pkg/console/subresource/deployment/deployment_test.go#L430-L431, `#L1534-L1535`, and `#L1875-L1876` with the same named constant.Source: Coding guidelines
🤖 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.
Nitpick comments:
In `@pkg/console/subresource/deployment/deployment.go`:
- Around line 185-188: Define a package-level constant for the non-HA rollout
percentage and update the RollingUpdateDeployment values in
pkg/console/subresource/deployment/deployment.go#L185-L188 to reuse it for
MaxSurge and MaxUnavailable. Replace the duplicated "25%" literals at
pkg/console/subresource/deployment/deployment_test.go#L430-L431, `#L1534-L1535`,
and `#L1875-L1876` with the same named constant.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: ce764740-5fb2-4064-9faf-524308fb1492
📒 Files selected for processing (4)
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yamlpkg/console/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_test.go
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
openshift/console(manual)
📜 Review details
🧰 Additional context used
📓 Path-based instructions (11)
bindata/assets/**/*.yaml
📄 CodeRabbit inference engine (ARCHITECTURE.md)
Store static YAML assets in
bindata/assets/organized by resource type (configmaps/, deployments/, pdb/, routes/, services/)
Files:
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yaml
**/*.{yaml,yml,json}
📄 CodeRabbit inference engine (Custom checks)
**/*.{yaml,yml,json}: Flag privileged: true, hostPID, hostNetwork, hostIPC, SYS_ADMIN capability, running as root without justification, and allowPrivilegeEscalation: true in container/Kubernetes manifests
When deployment manifests, operator code, or controllers are added/modified, ensure they do not introduce scheduling constraints assuming standard HA topology (3+ control-plane nodes, dedicated workers). Flag: required pod anti-affinity with maxUnavailable: 0 (deadlocks on SNO/TNF/TNA), pod topology spread with DoNotSchedule and hostname key (breaks on SNO), replica counts derived from node count without topology awareness, nodeSelector/node affinity targeting control-plane nodes (fails on HyperShift), scheduling to all control-plane nodes equally without excluding arbiter nodes (TNA), assuming dedicated worker nodes exist (SNO/TNF), or PodDisruptionBudgets designed for 3+ nodes (TNF/TNA). Do not flag if change checks ControlPlaneTopology, node counts, or topology labels before applying constraints.
Files:
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yaml
{manifests,bindata/assets,quickstarts,examples,profile-patches}/**/*.{yaml,yml}
📄 CodeRabbit inference engine (.claude/skills/manifest-review.md)
{manifests,bindata/assets,quickstarts,examples,profile-patches}/**/*.{yaml,yml}: Kubernetes manifests undermanifests/,bindata/assets/,quickstarts/,examples/, andprofile-patches/must include the appropriate cluster profile annotations when they are CVO-deployed resources (for exampleinclude.release.openshift.io/hypershift,include.release.openshift.io/ibm-cloud-managed,include.release.openshift.io/self-managed-high-availability, andinclude.release.openshift.io/single-node-developer).
Console resources in the manifest trees must include the capability annotationcapability.openshift.io/name: Console.
RBAC manifests must follow least-privilege design: grant only the permissions needed, avoid wildcards unless truly justified, use verbs that match the actual operation set, and set correctapiGroups(""for core APIs and specific groups for CRDs).
Resources must use the correct namespace for their role:openshift-consolefor console workload resources andopenshift-console-operatorfor operator resources; any cross-namespace reference must be explicit and intentional.
YAML manifests should use 2-space indentation, keep fields in a consistent order, and include---separators between multiple resources in the same file.
When binding roles to service accounts, useconsole-operatorin theopenshift-console-operatornamespace for operator cross-namespace access, and useconsolein theopenshift-consolenamespace for console workload-scoped access.
Files:
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yaml
**/*.yaml
⚙️ CodeRabbit configuration file
**/*.yaml: Review YAML manifests based on content and kind.Refer to /manifest-review when YAML contains:
kind: Roleorkind: ClusterRole(RBAC review)kind: RoleBindingorkind: ClusterRoleBindingannotations:section (check for cluster profiles)verbs: ["*"]or wildcard permissionsapiGroups: ["*"]or overly broad permissions- ServiceAccount references in subjects
Check for required annotations in manifests/:
include.release.openshift.io/hypershiftinclude.release.openshift.io/ibm-cloud-managedinclude.release.openshift.io/self-managed-high-availabilityinclude.release.openshift.io/single-node-developercapability.openshift.io/name: ConsoleFor quickstarts/, additionally check:
- QuickStart spec structure
- Task descriptions and prerequisites
- See quickstarts/README.md for guidelines
Files:
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yaml
**/*.{yaml,yml}
⚙️ CodeRabbit configuration file
**/*.{yaml,yml}: If this is a Kubernetes/OpenShift manifest or Helm template:
- securityContext: runAsNonRoot, readOnlyRootFilesystem,
allowPrivilegeEscalation: false- Drop ALL capabilities, add only what is required
- Resource limits (cpu, memory) on every container
- No hostPID, hostNetwork, hostIPC, privileged: true
- NetworkPolicy defined for the namespace
- OpenShift: SCC must be restricted or custom-scoped
- Liveness + readiness probes defined
- automountServiceAccountToken: false unless needed
- RBAC: least privilege; no cluster-admin for workloads
- Helm: no .Values interpolation in shell commands
Files:
bindata/assets/deployments/console-deployment.yamlbindata/assets/deployments/downloads-deployment.yaml
**/*.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
Usegofmtto format Go code with standard formatting
Rungo vetchecks on all Go packagesFollow 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 inpkg/api/, operator command setup inpkg/cmd/operator/, and version command inpkg/cmd/version/
**/*.go: Usegofmtfor 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 usingstatus.Handle*functions with type prefixes (*Degraded, *Progressing, *Available, *Upgradeable)
Use typed errors and wrap errors to preserve stack contextFlag MD5, SHA1, DES, RC4, 3DES, Blowfish, and ECB mode cryptographic usage. Also flag custom crypto implementations and non-constant-time comparison of secrets or tokens.
**/*.go: Do not use deprecated Go APIs such asioutil.ReadFile,ioutil.WriteFile,ioutil.ReadAll, ornet.DialinDialcallbacks; useos.ReadFile,os.WriteFile,io.ReadAll, andDialContextinstead.
When returning errors in Go, wrap them with%wand include meaningful context instead of returning the raw error or using%v.
Use specific error checks such asapierrors.IsNotFound(err)instead of matching error strings withstrings.Contains(err.Error(), ...).
Propagate the caller’scontext.Contextthrough operations and avoid replacing it withcontext.Background()inside request/controller code.
Usedeferto release acquired resources so cleanup happens on all return paths.
Avoid god functions: keep Go functions to roughly under 100 lines and split code with too many responsibilities into smaller...
Files:
pkg/console/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_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 functionsfactory.New().WithFilteredEventsInformers(pattern.ToController(method callsSync(ctx context.Context, controllerContext factory.SyncContext)methodsoperatorConfig.Spec.ManagementStatechecksstatus.NewStatusHandlerorstatus.Handle*functionsRefer to /sync-handler-review when code contains:
- Main operator sync functions (e.g.,
sync_v400.gocontent)- 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:
DialwithoutDialContext- Error handling: missing
%win 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/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_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 usinggofmt -w ./pkg ./cmd
Rungo vetchecks on all Go packages in ./pkg and ./cmd
Files:
pkg/console/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_test.go
pkg/console/subresource/**/*.go
📄 CodeRabbit inference engine (ARCHITECTURE.md)
Use
pkg/console/subresource/packages for resource builders, with separate packages for each resource type (authentication, configmap, deployment, oauthclient, route, secret, etc.)
Files:
pkg/console/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_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/subresource/deployment/deployment.gopkg/console/subresource/deployment/deployment_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
Usehttptestfor HTTP handler testing in Go
Include proper cleanup functions in tests
Test both success and failure pathsIn Go tests, do not ignore returned errors; check
errand fail the test witht.Fatalfort.Errorfas appropriate.
Files:
pkg/console/subresource/deployment/deployment_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/deepfor struct comparisons- Test naming conventions (TestFunctionName)
- Error handling with
wantErrpattern- 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 usagewait.Pollorwait.PollImmediatepatternsretry.RetryOnConflictfor updates- Cleanup via
deferfunctions- 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.Sleepinstead ofwait.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/subresource/deployment/deployment_test.go
pkg/**/*_test.go
📄 CodeRabbit inference engine (.claude/skills/unit-test-review.md)
pkg/**/*_test.go: Most unit tests should use the table-driven test pattern, including atests := []struct{...}table andt.Run(tt.name, ...)subtests for scenarios with multiple cases.
Test function names and subtest case names should be descriptive of the behavior or scenario being tested (for example,TestGetNodeComputeEnvironmentsor"Custom hostname and TLS secret set").
Usegithub.com/go-test/deep(deep.Equal) for struct comparisons instead of==or manual field-by-field checks.
Cover both success and failure paths in unit tests, including edge cases such as empty inputs, boundary values, missing fields, duplicates, and large inputs.
Structure tests using Arrange-Act-Assert so setup, execution, and verification are clearly separated.
When testing error-returning functions, assert error presence correctly and, when relevant, validate the error message substring instead of ignoring the error or discarding it with_.
Prefer dependency injection via interfaces for testability, and keep tests isolated so they do not depend on execution order or shared mutable state.
Extract repeated setup into helper functions when common test fixtures are reused across multiple tests.
Write specific, informative assertions that explain what failed instead of vague or silent failures.
Inline simple test data, but move complex fixtures to helper functions ortestdata/files.
Avoid tests that rely on execution order, share global mutable state, use hardcoded sleeps, omit assertions, or verify implementation details instead of behavior.
Files:
pkg/console/subresource/deployment/deployment_test.go
🔇 Additional comments (3)
bindata/assets/deployments/console-deployment.yaml (1)
10-11: LGTM!Also applies to: 28-33
bindata/assets/deployments/downloads-deployment.yaml (1)
11-12: LGTM!Also applies to: 29-31
pkg/console/subresource/deployment/deployment_test.go (1)
241-243: LGTM!Also applies to: 277-279, 322-324, 358-360, 403-405, 428-429, 432-437, 480-482, 516-518, 1736-1738, 1869-1873, 1877-1877, 1910-1912
|
@sg00dwin: 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. |
2 participants
What
Set API-server-defaulted fields explicitly in both deployment YAML templates (
console-deployment.yaml,downloads-deployment.yaml) and in the non-HA rolling update strategy code to prevent pathologicalDeploymentUpdatedevents.Fields added to YAML templates:
progressDeadlineSeconds: 600revisionHistoryLimit: 10dnsPolicy: ClusterFirstserviceAccount: <name>Code change:
withStrategy()now setsMaxSurge: "25%"andMaxUnavailable: "25%"for non-HA topologies instead of an empty structWhy
The console-operator generates pathological
DeploymentUpdatedevents in a tight reconciliation loop, causing 79% of test failures (15/19 runs) inperiodic-ci-openshift-release-main-nightly-5.0-e2e-vsphere-ovn-techpreview-serialwith a 1.9% overall pass rate.Library-go's
ApplyDeploymentWithForcereplaces the entire deployment spec on every metadata-triggered update (e.g., when a ConfigMap ResourceVersion changes due to plugin registration). Fields the operator didn't set are written as null, and the API server re-defaults them — creating unnecessary spec churn that doubles the update event count per trigger. With ~14 plugin registrations in a TechPreview test run, this produces ~30 events, exceeding the pathological threshold.Setting these fields explicitly makes the operator's desired spec match what the API server already stores, eliminating the null-field overwrite. Each legitimate trigger now produces exactly 1 deployment update instead of ~2.
All values are existing API server defaults — no behavioral change.
Verification
make test-unit)Fixes OCPBUGS-99943
Assisted by: Claude Code (Opus 4.6)
Summary by CodeRabbit