OCPBUGS-85060: feat: use 2 replicas for console on tnf

[eggfoobar]

Analysis / Root cause:

In TNF (Two Node Fencing) clusters we are currently only deploying a single replica console, this is causing issues during upgrade as one pod moves over to the other node and causes disruption. For all intents and purposes TNF should be considered like Arbiter and thus will require 2 replicas.

Solution description:

Updating the function to create the deployment with 2 replicas instead of 1.

Test setup:

Executing two node fencing upgrade payload job should not trigger
[Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should not change condition/Available failure

Test cases:

Browser conformance:

N/A

Additional info:

Reviewers and assignees:

Summary by CodeRabbit

• Bug Fixes
  • Console now correctly deploys in high availability mode when using dual replica topology, improving system resilience and availability across replica distribution and updates.

[openshift-ci-robot]

@eggfoobar: This pull request references Jira Issue OCPBUGS-85060, 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 New, which is one of the valid states (NEW, ASSIGNED, POST)

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

Details

In response to this:

Analysis / Root cause:

In TNF (Two Node Fencing) clusters we are currently only deploying a single replica console, this is causing issues during upgrade as one pod moves over to the other node and causes disruption. For all intents and purposes TNF should be considered like Arbiter and thus will require 2 replicas.

Solution description:

Updating the function to create the deployment with 2 replicas instead of 1.

Test setup:

Executing two node fencing upgrade payload job should not trigger
[Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should not change condition/Available failure

Test cases:

Browser conformance:

N/A

Additional info:

Reviewers and assignees:

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]

Walkthrough

The ShouldDeployHA function in the console deployment module now recognizes DualReplicaTopologyMode as an infrastructure topology that requires high-availability deployment mode, in addition to existing highly-available and highly-available-arbiter topologies.

Changes

HA Mode Detection

Layer / File(s)	Summary
Core Logic pkg/console/subresource/deployment/deployment.go	ShouldDeployHA condition expanded to include configv1.DualReplicaTopologyMode as a topology triggering HA deployment.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 11 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Test Structure And Quality	⚠️ Warning	PR adds DualReplicaTopologyMode to ShouldDeployHA but provides no test coverage for this new mode. Assertions also lack meaningful failure messages.	Add DualReplicaTopologyMode test cases to TestWithReplicas, TestWithAffinity, TestWithStrategy. Use meaningful assertion messages instead of plain t.Error(diff).

✅ Passed checks (11 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main change: adding 2 replicas for console deployment on TNF clusters, directly matching the PR's objective.
Description check	✅ Passed	The PR description covers most required sections: Analysis/Root cause, Solution description, and Test setup are well-filled; Browser conformance is marked N/A appropriately; Test cases section is incomplete but non-critical.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
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	PR does not introduce new tests or modify test files. Repository uses standard Go testing, not Ginkgo. The Ginkgo test name check is not applicable.
Microshift Test Compatibility	✅ Passed	The test added uses standard Go testing (testing.T), not Ginkgo e2e tests. The custom check applies only to Ginkgo tests (It, Describe, Context, When), so it is not applicable.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR adds deployment_replicas_test.go, a standard Go test, not Ginkgo. Custom check applies only to Ginkgo tests with It/Describe/Context patterns. Test is SNO-compatible.
Topology-Aware Scheduling Compatibility	✅ Passed	Topology-aware. Checks DualReplicaTopologyMode explicitly with correct constraints: 2 replicas, required anti-affinity, proper PDB. All topologies work correctly.
Ote Binary Stdout Contract	✅ Passed	PR modifies only deployment.go, a library package with business logic. No process-level code or stdout writes added. OTE Binary Stdout Contract check not applicable.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	No new Ginkgo e2e tests added. PR modifies deployment.go to support DualReplicaTopologyMode in ShouldDeployHA function using standard Go unit tests only.

_{✏️ 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.}

[eggfoobar]

/payload-job periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-upgrade periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ovn-two-node-fencing-upgrade

[openshift-ci]

@eggfoobar: trigger 2 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

• periodic-ci-openshift-release-main-nightly-4.22-e2e-metal-ovn-two-node-fencing-upgrade
• periodic-ci-openshift-release-main-nightly-5.0-e2e-metal-ovn-two-node-fencing-upgrade

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/75b4bc10-4a3f-11f1-926d-63d4ede17a0e-0

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: eggfoobar
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:

• 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]

@eggfoobar: This pull request references Jira Issue OCPBUGS-85060, 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:

Analysis / Root cause:

In TNF (Two Node Fencing) clusters we are currently only deploying a single replica console, this is causing issues during upgrade as one pod moves over to the other node and causes disruption. For all intents and purposes TNF should be considered like Arbiter and thus will require 2 replicas.

Solution description:

Updating the function to create the deployment with 2 replicas instead of 1.

Test setup:

Executing two node fencing upgrade payload job should not trigger
[Monitor:legacy-cvo-invariants][bz-Management Console] clusteroperator/console should not change condition/Available failure

Test cases:

Browser conformance:

N/A

Additional info:

Reviewers and assignees:

Summary by CodeRabbit

• Bug Fixes
• Console now correctly deploys in high availability mode when using dual replica topology, improving system resilience and availability across replica distribution and updates.

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]

🧹 Nitpick comments (1)

pkg/console/subresource/deployment/deployment.go (1)

141-146: ⚡ Quick win

Add table-driven tests for ShouldDeployHA topology permutations.

This helper now controls replicas, anti-affinity, and rollout strategy for DualReplicaTopologyMode; please add/extend tests for HighlyAvailable, HighlyAvailableArbiter, DualReplica, SingleReplica, and External + InfrastructureTopology combinations to lock behavior and avoid regressions.

🤖 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 141 - 146, Add
a table-driven unit test for the ShouldDeployHA function that enumerates
topology permutations: HighlyAvailableTopologyMode, HighlyAvailableArbiterMode,
DualReplicaTopologyMode, SingleReplica (or non-HA) mode, and the
ExternalTopologyMode combined with InfrastructureTopology ==
HighlyAvailableTopologyMode; for each case assert the expected boolean result.
Put the test in the same package (pkg/console/subresource/deployment) and
reference ShouldDeployHA and configv1.Infrastructure.Status.ControlPlaneTopology
/ InfrastructureTopology in the table entries so each permutation is clearly
named and validated to prevent regressions.

🤖 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 141-146: Add a table-driven unit test for the ShouldDeployHA
function that enumerates topology permutations: HighlyAvailableTopologyMode,
HighlyAvailableArbiterMode, DualReplicaTopologyMode, SingleReplica (or non-HA)
mode, and the ExternalTopologyMode combined with InfrastructureTopology ==
HighlyAvailableTopologyMode; for each case assert the expected boolean result.
Put the test in the same package (pkg/console/subresource/deployment) and
reference ShouldDeployHA and configv1.Infrastructure.Status.ControlPlaneTopology
/ InfrastructureTopology in the table entries so each permutation is clearly
named and validated to prevent regressions.

---

ℹ️ Review info

⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: d382e74d-0d42-4bbe-9162-f2422a7ac076

📥 Commits

Reviewing files that changed from the base of the PR and between 5ced247 and 08f533c.

📒 Files selected for processing (1)

• pkg/console/subresource/deployment/deployment.go

📜 Review details

🧰 Additional context used

📓 Path-based instructions (1)

pkg/**/*.go

⚙️ CodeRabbit configuration file

pkg/**/*.go: Review Go code following OpenShift operator patterns.
See CONVENTIONS.md for coding standards and patterns.
Controllers should use the library-go factory pattern.
Status conditions should use status.Handle* functions.

Files:

• pkg/console/subresource/deployment/deployment.go

[openshift-ci]

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