Comment 13 for bug 1804861

On Tue, Dec 4, 2018 at 10:30 AM Mathieu Trudel-Lapierre <
<email address hidden>> wrote:

> I disagree.
>
> We'd be working around a real design issue in systemd, rather that
>

While, I agree that having systemd-udev to apply MTU to devices is
less than ideal; I don't see having systemd or networkd growing
support for applying MTU values intelligently in the face of how several
key network devices in linux work (bonds and bridges utilize member
MAC values to function) happening any time soon.

This leaves netplan systems wanting to use bonds/bridges as they have
in Xenial/ifupdown regressed in functionality and requires (at least in the
MAAS case) existing products to update to work around netplan/networkd
MAC matching behavior that differs from what worked on Xenial.

Even if we "fixed" MAAS, there may be additional systems which generate
netplan configurations and expect that a bond or bridge will use the MAC
from one of the members. This impacts how switches and other off-system
devices are configured (port filtering by mac).

> possibly matching against Type=ethernet (if that existed). I think we
> should instead prioritize on avoiding this broken case in the other
> parts of the networking stack, and make sure we fix systemd to provide
> the right matching Type.
>

> Nothing guarantees that vlan, bridge, and bonds are the only types of
> devices affected and we're second-guessing the admin otherwise: I rather
>

I don't think we're second guessing anything; what I'm suggesting is that
when we examine the netplan yaml we have references to the bond or bridge
members, and we can determine what TYPE they are (or some other matching
element) and insert those into the bond match section to ensure it only
matches
for the interfaces with which the bond is configured.