Skip to content

OCPBUGS-83566: Branch Sync release-4.22 to release-4.21 [03-25-2026]#3087

Merged
openshift-merge-bot[bot] merged 93 commits intorelease-4.21from
sync-release-4.22-to-release-4.21-03-25-2026
Apr 16, 2026
Merged

OCPBUGS-83566: Branch Sync release-4.22 to release-4.21 [03-25-2026]#3087
openshift-merge-bot[bot] merged 93 commits intorelease-4.21from
sync-release-4.22-to-release-4.21-03-25-2026

Conversation

@openshift-pr-manager
Copy link
Copy Markdown

Automated branch sync: release-4.22 to release-4.21.

danwinship and others added 30 commits January 19, 2026 15:18
Signed-off-by: Dan Winship <danwinship@redhat.com>
Ignore whitespace differences.
Sort the output back into the "correct" order.

Signed-off-by: Dan Winship <danwinship@redhat.com>
Replace the custom HTTP server in StartMetricsServer with MetricServer.

Signed-off-by: Lei Huang <leih@nvidia.com>
A DPU firmware settings change can cause the same physical
port to be re-enumerated under a different PCI address after
a host reboot. Previously, Init() only handled missing device
IDs (legacy annotations). Now it also detects when the
annotated device ID is no longer present in the allocator and
falls back to matching by PfId and FuncId.

Signed-off-by: Yury Kulazhenkov <ykulazhenkov@nvidia.com>
Signed-off-by: Tim Rozet <trozet@nvidia.com>
`kind setup` starts to fail with error:
```
ERROR: failed to load image: command "docker exec --privileged -i ovn-worker
   ctr --namespace=k8s.io images import --all-platforms --digests
   --snapshotter=overlayfs -" failed with error: exit status 1

Command Output: ctr: content digest sha256:9c04829e9...: not found
```

Related kind issue is kubernetes-sigs/kind#3795.
This change uses the workaround mentioned in the kind issue.

Signed-off-by: Lei Huang <leih@nvidia.com>
fix kind load docker-image content digest not found
Signed-off-by: fangyuchen86 <fangyuchen86@gmail.com>
Signed-off-by: Patryk Diak <pdiak@redhat.com>
The node gateway logic was not taking into account dynamic UDN.
Therefore if a UDN was created with a service, but our node was not
active, then at start up during syncServices we would fail due to
GetActiveNetworkForNamespace failing. After 60 seconds of syncServices
failling, it would lead to OVN-Kube node crashing.

This commit introduces a common helper function to network manager
api, ResolveActiveNetworkForNamespaceOnNode, which will allow legacy
controllers that are not per-UDN or default controller to find the
primary network serving a namespace for their node.

The node/gateway is updated to use this function and during sync and
allows us to ignore objects for which the network is not on our node
with Dynamic UDN.

Additionally it does not fail syncServices when a network is not found.
During NAD controller start up, all networks will have been processed.
If by the time gateway starts up and the network is missing, that means
it is a new event which this node has never seen before. Therefore it is
safe to skip it during syncServices and allow initial add handling to
take care of it later.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Network Policy add was not taking into account dynamic UDN. This was not
a problem for the layer2/layer3 UDN controller side, because if the node
was inactive, then the controllers wouldn't exist. However, it was a
problem for the default network controller, because if the DNC could not
get the active network, it would error and retry to add the KNP over and
over again for other UDNs.

This fixes it by checking the nad controller cache instead, which will
always have the full info to determine if the KNP belongs to CDN.

Furthermore, the delete KNP path was incorrect. It would try to get the
active network which could be gone during deletion. This was unnecessary
as the deleteNetworkPolicy code will check to see if it actually
configured it in the first place, making it a noop to always call
delete.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Needed to be updated for the same reasons as network policy. Services
controller is per UDN, and with an inactive node this is not a problem
for UDN controllers as they will not exist. However, for DNC it would
continue failing to get active network here. Use the nad controller
cache and shortcut the checks for default network controller.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Should always just return default network in that case.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
EF calls GetActiveNetworkForNamespace in an initialSync migration
function. This function moves from cluster port group to namespace pgs.
It is old and could be argued to just remove the code, but for now move
to use nad controller cache. Also, do not cause OVNK to exit if we
cannot get the network name, and just skip that entity.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Egress IP controller runs as part of DNC, is event driven, and retries
on failures. It is also not dynamic UDN aware. This commit aims to fix
this by:

 - Change EgressIP to check with nad controller for network presence
 - If network is not processed/invalid skip retrying in egress IP
   controller
 - Register NAD Reconciler for Egress IP, so that when network becomes
   active Egress IP handles reconciliation.
 - If dynamic UDN is enabled, filter out EgressIP operations for
   inactive nodes.

Overall this should be a quality of life improvement to EgressIP and
reduce unnecessary reconcilation with UDN. Future steps will be to break
Egress IP into its own level driven controller.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Adds a test that creates a primary + secondary UDN, pod, egress IP, KNP,
MNP objects in those UDNs. Then restarts every ovnkube-pod, and ensures
it comes back up in ready state. This is useful in general to make sure
we survive restarts correclty, but especially useful for Dynamic UDN
where a network may not be active on a node and we want to ensure start
up syncing is not failing because of that.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
When a pod is recreated with the same name, the egressIP cache could already
contain a “served” {EgressIP,Node} status and skip programming as a no-op.
Since statusMap keys do not include pod IP, LRP/NAT state could remain stale
and traffic would miss egressIP SNAT.

Fix by detecting pod IP drift from podAssignment.podIPs and forcing a
delete+add reprogram for already-applied statuses:
 - compare cached pod IPs to current pod IPs
 - queue existing statuses for reprogram on IP change
 - delete old assignment state (without standby promotion) and re-add it
 - then update cached pod IPs

Signed-off-by: Tim Rozet <trozet@nvidia.com>
EgressIP pod handling assumes pod networking setup has already populated
logicalPortCache before egressIP reconciliation runs. That ordering holds
within one controller queue, but breaks for primary UDNs where pod setup
runs in UDN controllers while egressIP pod reconcile runs in the default
controller.

In that cross-controller race, egressIP reconcile can run first, fail to get
pod IPs (stale/missing LSP), and wait for normal retry cadence even after UDN
later updates port cache.

Fix by wiring an immediate egressIP pod retry on logicalPortCache add:
- add a base controller callback hook for logicalPortCache add events
- invoke it from default/UDN pod logical port add paths
- hook it for primary UDN controllers to enqueue no-backoff egressIP pod retry
- centralize retry logic in eIPController.addEgressIPPodRetry()
  (including PodNeedsSNAT filtering)

This preserves existing behavior while removing the UDN/DNC ordering race
window for egressIP pod programming.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Removes UnprocessedActiveNetwork Error, and moves to just using a single
error, InvalidPrimaryNetworkError for everything. Modifies
GetActiveNetworkForNamespace to return nil when there is no active
network due to namespace being removed, or Dynamic UDN filtering.
Callers can then rely on this function to determine whether or not a
network is active versus the network should exist but doesn't (an
error).

Walked through all callers of GetActiveNetworkForNamespace and
GetPrimaryNADForNamespace and tried to simplify number of calls and
logic.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
- Removes a second call to GetActiveNetworkForNamespace during egress
  firewall add. We can just use the cache object that already exists.

- Restructure the cache object to be a slice of subnets, rather than a
  string key.

- Fix util function CopyIPNets, which was not doing a deep copy of
  the underlying IP/Mask slices.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Code was modifying the annotations of the informer cache node object. If
this was happening while another goroutine was reading the annotation
map, it would trigger ovnkube to crash!

Fixes: #5950

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Signed-off-by: Tim Rozet <trozet@nvidia.com>
Gateway egress IP adds IPs to an annotation on the node. The code was
assuming the informer object should have the latest data, then
overwriting the IPs using that information. That isn't reliable as the
informer could have stale data compared to recent kubeclient updates.
This would trigger egress IP logic to corrupt the IPs in the node
annotation, and cause further drift/corruption in subsequent updates.

This fixes it by creating a local cache of IPs for the controller, and
using that as the source of truth, initialized on start up from the node
object. Then updates are driven by what is in the cache, versus what is
in the informer.

Also fixes places where tests should have been using Eventually.

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Signed-off-by: fangyuchen86 <fangyuchen86@gmail.com>
EgressIP: Fix crash from mutating node informer object
Fixes missing Dynamic UDN integration, Incorrect logic with GetActiveNetworkForNamespace, adds EgressIP NAD Reconciler
In Egress IP tracker when GetPrimaryNADForNamespace returns an
InvalidPrimaryNetworkError we return nil during the sync, as we expect
the NAD controller to deliver the event later when the NAD is processed.

However, in this UT there is no full NAD controller and it relies on the
lister. Therefore the UT may run before the informer cache is populated
and never get notified from the "NAD Controller". To fix it, wait until
the informer cache is populated and then simulate the NAD Controller
behavior by Reconciling the NAD key.

Fixes: #5953

Signed-off-by: Tim Rozet <trozet@nvidia.com>
Skip namespaces with deletionTimestamp set when selecting target
namespaces, triggering NAD deletion for terminating namespaces.

Signed-off-by: Patryk Diak <pdiak@redhat.com>
@kyrtapz
Copy link
Copy Markdown
Contributor

kyrtapz commented Apr 16, 2026

/lgtm

@openshift-ci openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Apr 16, 2026
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Apr 16, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kyrtapz, openshift-pr-manager[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described 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

@openshift-ci openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 16, 2026
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci Bot commented Apr 16, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kyrtapz, openshift-pr-manager[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described 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

@arkadeepsen
Copy link
Copy Markdown
Member

/retitle OCPBUGS-83566: Branch Sync release-4.22 to release-4.21 [03-25-2026]

@openshift-ci openshift-ci Bot changed the title NO-JIRA: Branch Sync release-4.22 to release-4.21 [03-25-2026] OCPBUGS-83566: Branch Sync release-4.22 to release-4.21 [03-25-2026] Apr 16, 2026
@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 Apr 16, 2026
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@openshift-pr-manager[bot]: This pull request references Jira Issue OCPBUGS-83566, which is invalid:

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:

Automated branch sync: release-4.22 to release-4.21.

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.

@arkadeepsen
Copy link
Copy Markdown
Member

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

@arkadeepsen: This pull request references Jira Issue OCPBUGS-83566, which is valid. The bug has been moved to the POST state.

7 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (4.21.z) matches configured target version for branch (4.21.z)
  • bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)
  • release note text is set and does not match the template
  • dependent bug Jira Issue OCPBUGS-83565 is in the state Closed (Done), which is one of the valid states (VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA))
  • dependent Jira Issue OCPBUGS-83565 targets the "4.22.0" version, which is one of the valid target versions: 4.22.0
  • bug has dependents
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.

@arkadeepsen
Copy link
Copy Markdown
Member

Adding the verified label as the linked bug is a dummy one to get the jira/valid-bug label.

/verified by CI

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Apr 16, 2026
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@arkadeepsen: This PR has been marked as verified by CI.

Details

In response to this:

Adding the verified label as the linked bug is a dummy one to get the jira/valid-bug label.

/verified by CI

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.

@arkadeepsen
Copy link
Copy Markdown
Member

/tide refresh

@openshift-merge-bot
Copy link
Copy Markdown
Contributor

/retest-required

Remaining retests: 0 against base HEAD 020d072 and 2 for PR HEAD ec47d40 in total

@arkadeepsen
Copy link
Copy Markdown
Member

/test e2e-aws-ovn-hypershift

@openshift-merge-bot openshift-merge-bot Bot merged commit 7c69414 into release-4.21 Apr 16, 2026
59 checks passed
@openshift-ci-robot
Copy link
Copy Markdown
Contributor

@openshift-pr-manager[bot]: Jira Issue Verification Checks: Jira Issue OCPBUGS-83566
✔️ This pull request was pre-merge verified.
✔️ All associated pull requests have merged.
✔️ All associated, merged pull requests were pre-merge verified.

Jira Issue OCPBUGS-83566 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓

Details

In response to this:

Automated branch sync: release-4.22 to release-4.21.

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-merge-robot
Copy link
Copy Markdown
Contributor

Fix included in release 4.21.0-0.nightly-2026-04-16-223638

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

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. backport-risk-assessed Indicates a PR to a release branch has been evaluated and considered safe to accept. 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. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.