The problem is that DEVTYPE is unreliable at best. Using the MAC of one
of the member interfaces is fine, but only if you really know what
you're doing.
I think we're otherwise back to matching by name instead of by MAC
address (or matching both), if you want to match "like ifupdown was
doing".
This is why we should fix networkd -- I don't think it's a difficult
thing to do at all to say, have it grow an actual value for DEVTYPE
rather than null, nor would be be complicated to then write
Type=ethernet in the .link files generated, provided that the syntax
also read 'match: { type: ethernet }'... or perhaps even not. We can do
this fix ourselves, I'm just pointing out that it has the potential of
being a bit disruptive, because ethernets have long had no DEVTYPE value
in udev (it's been a PITA for a while).
*Then* we can improve the matching logic in netplan, but I don't think
we should do that before we have the right facilities in systemd to do
so.
In the interim; I still do think it would be best for maas/juju and
whatever not to assume that using the MAC address for the first phy is
the right thing to do.
And before then, workaround is to explicitly define a MAC address for
the device when defining the bond or bridge rather than using defaults.
The logic is simple: the kernel and systemd already do the right thing
if no MAC is set at all, so it could just as well be omitted completely
from the netplan syntax generated by the different install tools. If you
must write one, then you can always come up with one in a range that
will not clash with other devices on the network.
I'm not against finding a suitable workaround in netplan, but so far I
haven't seen anything that seemed sufficiently solid, and let's be
honest: those remain workaround to paper over other issues that we
really should be fixing instead.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1804861
Title:
MTU size defined on /etc/netplan/50-cloud-init.yaml not applied
To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1804861/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
