-
Notifications
You must be signed in to change notification settings - Fork 1.1k
dhcp: add option to use NetworkManager for DHCP discovery #5563
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,7 +12,7 @@ After=systemd-remount-fs.service | |
| Requires=dbus.socket | ||
| After=dbus.socket | ||
| {% endif %} | ||
| Before=NetworkManager.service | ||
| After=NetworkManager.service | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This will break some cloud-init expectations, so I don't think that we can accept this as it is. We could always just patch it for downstreams using NetworkManager, but this would leave cloud-init differently on different distributions, and it really misses the point of what the local stage is supposed to be doing. It might be that cloud-init doesn't really need to get a network configuration before the daemon is up for datasources that require network - if that is true then we could always use the "activator" codepath - but that would change things like what hostname is advertised to the DHCP server (iirc there is a bug related to this). Thoughts @cjp256? Either way if we go down that route, this code proposal would have to make some changes and that would be a big architectural change - so let me think about this a bit. |
||
| {% if variant in ["almalinux", "cloudlinux", "rhel"] %} | ||
| Before=network.service | ||
| {% endif %} | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't looked at this code thoroughly, but it does appear to have the same shortcoming as the udhcpc implementation: missing azure support for option 245.
cc @cjp256
On azure I see this:
So we have access to the wireserver IP address, but this PR doesn't seem deal with this special option correctly.