[RETEST] OCPBUGS-88063: ovn-kubernetes: Move MNP from ConfigMap to CLI flags - #3103
[RETEST] OCPBUGS-88063: ovn-kubernetes: Move MNP from ConfigMap to CLI flags#3103weliang1 wants to merge 1 commit into
Conversation
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>
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
Skipping CI for Draft Pull Request. |
|
@weliang1: This pull request references Jira Issue OCPBUGS-88063, 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. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: weliang1 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 |
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:
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
--enable-multi-networkpolicyCLI flag--enable-multi-networkpolicyCLI flagTesting Focus
Related
DO NOT MERGE - This is identical to already-merged PR #3072
/hold