Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read lease files from dhclient and NetworkManager on Azure and CloudStack #146

Closed
jlebon opened this issue Jan 14, 2019 · 6 comments · Fixed by #861
Closed

Read lease files from dhclient and NetworkManager on Azure and CloudStack #146

jlebon opened this issue Jan 14, 2019 · 6 comments · Fixed by #861

Comments

@jlebon
Copy link
Member

jlebon commented Jan 14, 2019

RHCOS/FCOS uses NetworkManager presently. So the logic to look for option 245 in the systemd-networkd lease file would need to be adapted to read from those lease files (/var/lib/NetworkManager on RHEL7, /var/lib/dhclient on FCOS and likely RHEL8). Might be worth investigating if NM's D-Bus API exposes this so we don't have to learn dhclient's syntax.

Though note that this is not a blocker for getting those platforms on Azure if we're comfortable relying exclusively on the fallback endpoint (#145) until this is implemented.

Related: #130

@bgilbert bgilbert changed the title Teach coreos-assembler on Azure to read lease files from dhclient and NetworkManager Read lease files from dhclient and NetworkManager on Azure and CloudStack Jan 14, 2019
@bgilbert
Copy link
Contributor

The CloudStack provider also reads networkd lease files via a call to dns_lease_key_lookup().

@lucab
Copy link
Contributor

lucab commented Jun 26, 2020

We should be now in a better position to tackle this, as at least we have a single network management stack in initramfs in both RHCOS and FCOS (NM with the internal DHCP client).

@lucab lucab added jira for syncing to jira and removed jira for syncing to jira labels Jul 29, 2020
@lucab
Copy link
Contributor

lucab commented Jul 29, 2020

For reference, NM lease files do not seem to contain the DHCP option:

cat /var/lib/NetworkManager/internal-054597c7-5830-47a8-a54c-77e054ee00aa-eth0.lease 

# This is private data. Do not parse.
ADDRESS=10.1.42.5

@lucab
Copy link
Contributor

lucab commented Sep 26, 2022

To make this ticket easier to find out, this bug currently means that on Azure we have to wait for a timeout:

[  131.232431] afterburn[1103]: WARN Failed to get fabric address from DHCP: maximum number of retries (60) reached
[  131.244800] afterburn[1103]: INFO using fallback address

It it gets too annoying to have this timeout, we could try to add some smarter heuristic in Afterburn in order to directly reach the Azure hardcoded IP.

@bgilbert
Copy link
Contributor

This is causing a 30 second boot delay in Azure on Fedora CoreOS (#652).

@bgilbert bgilbert added the jira for syncing to jira label Jan 12, 2023
@bgilbert
Copy link
Contributor

bgilbert commented Jan 16, 2023

The boot delay is caused by (at least) afterburn-hostname.service. These days we have a NetworkManager daemon and D-Bus in the initrd, so a D-Bus query should be sufficient. Here's a sample query on a RHEL 8 instance (not tested in the initrd), based on this:

#!/usr/bin/python3
import dbus
bus = dbus.SystemBus()
nm = bus.get_object("org.freedesktop.NetworkManager", "/org/freedesktop/NetworkManager")
conn = bus.get_object("org.freedesktop.NetworkManager", nm.Get("org.freedesktop.NetworkManager", "PrimaryConnection", dbus_interface="org.freedesktop.DBus.Properties"))
dhcp = bus.get_object("org.freedesktop.NetworkManager", conn.Get("org.freedesktop.NetworkManager.Connection.Active", "Dhcp4Config", dbus_interface="org.freedesktop.DBus.Properties"))
options = dhcp.Get("org.freedesktop.NetworkManager.DHCP4Config", "Options", dbus_interface="org.freedesktop.DBus.Properties")
print(str(options["private_245"]))

Output:

a8:3f:81:10

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

Successfully merging a pull request may close this issue.

4 participants