Conversation
find [DHCP] in netplan/src/networkd.c compare systemd/src/network/networkd-network-gperf.gperf also see systemd.network(5)
no change in generated configuration intended
no-op
slyon
left a comment
There was a problem hiding this comment.
Thank you very much for your contribution to Netplan. And my apologies, this PR fell through the cracks!
I see this PR is still pretty much in "Draft" state (as indicated) with plenty of commented lines and "FIXMEs" inside.
Your PR description sounds like a bug report to me, would you mind creating an official bug report on https://bugs.launchpad.net/netplan/+filebug Describing the new functionality available in networkd today and how it breaks Netplan's current behaviour?
|
@slyon (edit: incorrect ping) I had given up on a proper fix because systemd changed that code a few times and there was no way one netplan version could serve all of them in a simple fashion. Maybe this needs to be fixed in a only-to-be-used-with-systemd-v250+ version and after requesting systemd to document as stable everything netplan uses. |
networkd renamed section DHCP=>DHCPv4. Two options had been documented at the time, they include DHCPv6:
systemd/systemd@4f7331a - Not so most of the others. They need to move to DHCPv6 section.
Any guidelines on such breaking change?
This will cause trouble with incompletely applied (yet not generating warnings) configurations that, by chance, work now, e.g.:
It won't suffice to just teach
combine_dhcp_overrides()that most options must and all options should go into separate sections. Admins must somehow be able to discover why their effective configuration changed.References:
man 5 systemd.network
https://github.com/canonical/netplan/tree/main/src/networkd.c
https://github.com/systemd/systemd/tree/main/src/network/networkd-network-gperf.gperf
DHCP.UseHostname => DHCPv4.UseHostname
systemd/systemd@1346b1f
systemd/systemd#13006
DHCPv6.UseFQDN => DHCPv6.UseHostname
systemd/systemd#18543
systemd/systemd#18668