Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2151040

Summary: Prevent reaching network-online.target/NetworkManager-wait-online while nm-cloud-setup is still working
Product: Red Hat Enterprise Linux 9 Reporter: Thomas Haller <thaller>
Component: NetworkManagerAssignee: Wen Liang <wenliang>
Status: CLOSED ERRATA QA Contact: David Jaša <djasa>
Severity: medium Docs Contact: Jaroslav Klech <jklech>
Priority: medium    
Version: 9.1CC: bgalvani, cfeist, desktop-qa-list, fdanapfe, ferferna, fpokryvk, gfialova, jklech, lrintel, nm-team, oalbrigt, rkhan, sfaye, sukulkar, thaller, till, vbenes, wenliang
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: NetworkManager-1.43.10-1.el9 Doc Type: Bug Fix
Doc Text:
.The `nm-cloud-setup` service no longer removes manually-configured secondary IP addresses from interfaces Based on the information received from the cloud environment, the `nm-cloud-setup` service configured network interfaces. While you had the option to disable `nm-cloud-setup` for manual interface configuration, certain scenarios led to conflicts. In some cases, other services on the host would independently configure interfaces, including the addition of secondary IP addresses. `nm-cloud-setup` incorrectly removed these secondary IP addresses when triggered again by the `systemd` timer unit. This update for the `NetworkManager` package fixes the problem. You only need to wait for the `systemd` timer unit to trigger `nm-cloud-setup`. If you do not want to wait for the timer, you can enable `nm-cloud-setup` manually with the following command: ---- # systemctl enable nm-cloud-setup.service ---- As a result, `nm-cloud-setup` no longer removes manually-configured secondary IP addresses from interfaces.
 Story Points: ---
Clone Of: 2132754 Environment:
Last Closed: 2023-11-07 08:37:53 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2132754    
Bug Blocks:    

Description Thomas Haller 2022-12-05 23:58:42 UTC 
+++ This bug was initially created as a clone of Bug #2132754 +++

nm-cloud-setup reconfigures the network. It does so frequently and automatically. It is also enabled by default in RHEL cloud images.

When doing that, it removes IP addresses that are not expected. That causes problems, for services that add IP addresses on the interface (by not using NetworkManager API but netlink/iproute2 directly).

The solution will be two fold:

1) bug 2132754: nm-cloud-setup uses Reapply() D-Bus call. The Reapply() call will get a new flag "preserved-external-ip", so that NetworkManager leaves externally configured IP addresses/routes on the interface alone.

2) this rhbz. When the device/connection activates, it should stay in "activating" state until nm-cloud-setup completed and configured additional addresses. This will also delay "NetworkManager-wait-online.service" and "network-online.target" and allows the user to order themselves after nm-cloud-setup is done.



Note that we could solve the ordering partially by only delaying network-online.target. For that, there could be a service which prevents "network-online.target" to be reached while nm-cloud-setup is still running. However, it would be nicer if you can also see in `nmcli device` that the device is still in "activating" state. We have a mechanism for that, the dispatcher "pre-up" event. We need to install a pre-up script which blocks activation while nm-cloud-setup is running. The pre-up script runs pretty late in the activation, when the interface is otherwise mostly configured.

One problem is that nm-cloud-setup does not run per-interface. It runs and configures all interfaces. If then a pre-up event comes for eth0 and eth1, then they both need to block until nm-cloud-setup is complete. That might be slightly compliated to get right (but maybe not. A `systemctl restart nm-cloud-setup.service` in the pre-up dispatcher script might be sufficient).

Another downside is that eth0 and eth1 both need to wait for nm-cloud-setup to complete. Maybe eth0 could complete faster. But that seems not a big problem.


I think all this needs is a blocking "pre-up" script that calls `systemctl restart nm-cloud-setup.service` and waits for it to complete.
Comment 4 David Jaša 2023-08-01 13:23:24 UTC 
VERIFIED with NetworkManager-1.43.11-1.el9.x86_64: an address added via 'ip addr add ...' before nm-cloud setup is run is present afterwards as well.
Comment 11 errata-xmlrpc 2023-11-07 08:37:53 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6585