On Tue, Dec 4, 2018 at 12:31 PM Mathieu Trudel-Lapierre <
<email address hidden>> wrote:

> 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
>

DEVTYPE is a kernel device property that udev exports into systemd/networkd

so it's not an easy fix to networkd; it's kernel patches for all net
devices.


> 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).
>

Hrm, you seen to agree that we don't have this property from udev and it's
going to be
a problem, so I'm confused about what you're proposing to do in networkd.


>
> *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.
>

I think for any of the devices that may be members of a composed device, we
can find out udev properties which can be used in the Match section for
.link
files to filter out any device besides the composed device members.



> 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.
>

It's not that maas/juju assume it's the right thing to do, it's what
happens in linux
networking by default (in the absence of providing a dedicated MAC value
for the
bond or bridge).  This is the convention that currently doesn't work under
netplan
when it comes to applying MTU due to the [Match] were generating.


>
> And before then, workaround is to explicitly define a MAC address for
> the device when defining the bond or bridge rather than using defaults.
>

I'll let the field folks comment on whether that's something that's doable
I suspect in a case-by-case basis it may, but generally this adds burden
to deployments which work fine on Xenial, but not on Bionic.


> 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
>

Even if this works, it's not an easy thing to ensure that the network
configuration
that MAAS sends to deployed systems omits a mac address for the bond.
At minimum it's a big SRU on all of the supported releases.


> 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.
>

I don't consider filtering the .link files with additional systemd-udev
primitives
that exist today as papering over things.  I do think that we can determine
and
emit a tighter filter on the Match section for .link files netplan
generates.  I'm
interested if you see an counter cases where such a thing would cause
issues.

I don't think there is a valid use-case for having the MTU value on one of
our configuration
elements (physical link in a bond) to apply to other network devices in the
system (even if they
happen to have the same MAC).  That surprising behavior given a netplan
yaml which specifies
a different MTU on the vlan vs. what's set on the physical links.

We have two places to affect things.  1) in the systemd config we render 2)
networkd behavior
I think if netplan can get systemd to configure in the interfaces per the
yaml via how it renders systemd
config, that's preferred over getting networkd to grow new features or
different behavior.





>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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
>