Skip to content

[RETEST] OCPBUGS-88063: ovn-kubernetes: Move MNP from ConfigMap to CLI flags - #3103

Draft
weliang1 wants to merge 1 commit into
openshift:masterfrom
weliang1:retest-pr-3072
Draft

[RETEST] OCPBUGS-88063: ovn-kubernetes: Move MNP from ConfigMap to CLI flags#3103
weliang1 wants to merge 1 commit into
openshift:masterfrom
weliang1:retest-pr-3072

Conversation

@weliang1

@weliang1 weliang1 commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

⚠️ Retest of Merged PR #3072 - For CI Validation Only

This PR contains the exact same changes as the already-merged PR #3072 for CI testing purposes.

Original PR

Summary

MultiNetworkPolicy is not enforced on UDN secondary interfaces in OCP 5.0 because ovnkube-control-plane pods do not restart when the ConfigMap is updated with enable-multi-networkpolicy=true.

Root Cause

PR #2944 moved MNP enablement to ConfigMap, but:

  1. The ConfigMap hash only includes 008-script-lib.yaml, not 004-config.yaml
  2. ovnkube-control-plane has no hash annotation to trigger restarts

Solution

Follow the same pattern as commit f4734c5 (OCPBUGS-78731): move MNP back to CLI flags where pod restart happens automatically on spec changes.

This creates consistency with multicast (also a CLI flag) and avoids the ConfigMap hash timing issues.

Changes

  • managed/004-config.yaml: Remove MNP from both ConfigMaps (HyperShift nodes + control plane)
  • managed/ovnkube-control-plane.yaml: Add --enable-multi-networkpolicy CLI flag
  • self-hosted/004-config.yaml: Remove MNP from ConfigMap
  • self-hosted/ovnkube-control-plane.yaml: Add --enable-multi-networkpolicy CLI flag
  • ovn_kubernetes_test.go: Update test expectations
  • docs/ovn_node_mode.md: Document ConfigMap vs CLI flag feature enablement mechanisms

Testing Focus

  • ✅ CI job execution and validation
  • ✅ MNP enforcement on UDN Layer2 and Layer3 networks
  • ✅ Upgrade paths (4.x → 5.0)
  • ✅ HyperShift managed control plane
  • ✅ DPU-host mode compatibility
  • ✅ Test cases: OCP-77656, OCP-78125, OCP-78259, OCP-77657

Related


DO NOT MERGE - This is identical to already-merged PR #3072

/hold

MultiNetworkPolicy is not enforced on UDN secondary interfaces in OCP 5.0
because ovnkube-control-plane pods do not restart when the ConfigMap is
updated with enable-multi-networkpolicy=true.

Root cause: PR openshift#2944 moved MNP enablement to ConfigMap, but:
1. The ConfigMap hash only includes 008-script-lib.yaml, not 004-config.yaml
2. ovnkube-control-plane has no hash annotation to trigger restarts

Solution: Follow the same pattern as commit f4734c5 (OCPBUGS-78731):
move MNP back to CLI flags where pod restart happens automatically on
spec changes.

This creates consistency with multicast (also a CLI flag) and avoids the
ConfigMap hash timing issues that caused the original NVIDIA-554 fix to
be reverted.

How to verify:
1. Deploy cluster with UseMultiNetworkPolicy=false
   - Verify ovnkube-control-plane pods lack --enable-multi-networkpolicy flag
2. Set UseMultiNetworkPolicy=true via network.operator/cluster
   - Verify ovnkube-control-plane pods restart with --enable-multi-networkpolicy
3. Test MNP enforcement on UDN Layer2/Layer3 networks
4. Verify DPU-host mode still works correctly
5. CI lanes: e2e-aws-ovn, e2e-gcp-ovn, e2e-metal-ipi-ovn-dualstack

Tested:
- MNP works on UDN Layer2 and Layer3 networks
- Pods restart when UseMultiNetworkPolicy changes
- DPU-host mode still works correctly
- Other ConfigMap features (egress-ip, etc.) unaffected

Jira: OCPBUGS-88063

docs: Clarify CLI flags are for control-plane pod restarts

Update ovn_node_mode.md to specify that CLI flags are used for features
requiring ovnkube-control-plane pod restarts, not just any pod restarts.
This clarifies that ovnkube-node pods already restart when the ConfigMap
changes, so CLI flags are only needed for control-plane-specific features.

Addresses review feedback from danwinship.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
@openshift-merge-bot

Copy link
Copy Markdown
Contributor

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 openshift-ci Bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Aug 4, 2026
@openshift-ci

openshift-ci Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

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-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. labels Aug 4, 2026
@openshift-ci-robot

Copy link
Copy Markdown
Contributor

@weliang1: This pull request references Jira Issue OCPBUGS-88063, which is invalid:

  • expected the bug to be in one of the following states: NEW, ASSIGNED, POST, but it is Verified 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:

⚠️ Retest of Merged PR #3072 - For CI Validation Only

This PR contains the exact same changes as the already-merged PR #3072 for CI testing purposes.

Original PR

Summary

MultiNetworkPolicy is not enforced on UDN secondary interfaces in OCP 5.0 because ovnkube-control-plane pods do not restart when the ConfigMap is updated with enable-multi-networkpolicy=true.

Root Cause

PR #2944 moved MNP enablement to ConfigMap, but:

  1. The ConfigMap hash only includes 008-script-lib.yaml, not 004-config.yaml
  2. ovnkube-control-plane has no hash annotation to trigger restarts

Solution

Follow the same pattern as commit f4734c5 (OCPBUGS-78731): move MNP back to CLI flags where pod restart happens automatically on spec changes.

This creates consistency with multicast (also a CLI flag) and avoids the ConfigMap hash timing issues.

Changes

  • managed/004-config.yaml: Remove MNP from both ConfigMaps (HyperShift nodes + control plane)
  • managed/ovnkube-control-plane.yaml: Add --enable-multi-networkpolicy CLI flag
  • self-hosted/004-config.yaml: Remove MNP from ConfigMap
  • self-hosted/ovnkube-control-plane.yaml: Add --enable-multi-networkpolicy CLI flag
  • ovn_kubernetes_test.go: Update test expectations
  • docs/ovn_node_mode.md: Document ConfigMap vs CLI flag feature enablement mechanisms

Testing Focus

  • ✅ CI job execution and validation
  • ✅ MNP enforcement on UDN Layer2 and Layer3 networks
  • ✅ Upgrade paths (4.x → 5.0)
  • ✅ HyperShift managed control plane
  • ✅ DPU-host mode compatibility
  • ✅ Test cases: OCP-77656, OCP-78125, OCP-78259, OCP-77657

Related


DO NOT MERGE - This is identical to already-merged PR #3072

/hold

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 openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Aug 4, 2026
@coderabbitai

coderabbitai Bot commented Aug 4, 2026

Copy link
Copy Markdown

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: d663a400-606b-44b5-a989-84a4879a3951

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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

@openshift-ci

openshift-ci Bot commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Labels

do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. 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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants