[systemd-devel] Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?

[Thomas Haller]

On Thu, 2022-05-12 at 18:41 +0200, Lennart Poettering wrote:
> On Mo, 09.05.22 19:27, Zbigniew Jędrzejewski-Szmek
> (zbyszek at in.waw.pl) wrote:
> 
> > FWIW, I still think it's a better _default_. The patch that finally
> > introduced this was my patch [1], so I'm obviously biased… Some
> > more
> > considerations:
> 
> I agree with this.
> 
> Finding good defaults is always difficult, but I must say stability
> and predictability is a property I like above a lot of other stuff. I
> understand that in plenty environments it's important not to add new
> MAC addresses to the mix, but it's impossible to know in which
> environment we are.

Most devices are created by tools that intentionally choose the MAC
address. So this primarily matters for simpler tools.

The predictability comes at the expense of introducing races. Races
that theoretically already exist when you don't wait for udev to
complete initialization. But which in practice are not be harmful,
because udev does not do much of relevance for software devices
(MacAddressPolicy= aside). I am surprised that this race doesn't bother
more people. It seems more severe to me than the bond/bridge problem
that Dusty is about. Because that is just an undesired configuration,
that can be changed.

> 
> So, either way, some people will always be unhappy with the defaults
> we pick. Changing defaults makes sense if it's highly likely that the
> vast majority of users would benefit from the new default. But I
> don't
> see that here... And changing defaults comes at a price, because it
> will break people's setup. We made a change once here, but I wouldn't
> use that as excuse to change it again...

Maybe we can just accept that RHEL8/9/10 won't have this behavior.
After all, not every default may be best for very distro. In case of
CoreOS, maybe that applies to some Fedora spins as well.


> 
> So, I am not convinced.
> 
> What makes me wonder about all of this: we are talking about
> synthetic
> devices, which means some tool is used to create them. If those tools
> prefer a different MAC policy, why don't they drop in a .link file
> that matches against the devices that specific software creates?

NetworkManager doesn't mind. NetworkManager sets a MAC address (or
doesn't) and udev too. Everything happens according to configuration.
NetworkManager won't fight udev's configuration, or try to overrule
it. It's the user's choice... Except, this choice here comes from the
distro and seems to cause problems for some users.

If we really wanted to overule this, we would install a 98-nm-
default.conf, and don't bother with ID_NM_OWNED_AND_OPERATED=1. That
essentially happens on RHEL already, by patching 99-default.conf.

> 
> i.e. let's say NM prefers to use a different MAC policy: they could
> drop in a udev rules file that adds some udev property onto the
> network devices they manage (i.e. invoke a callout binary, or do a
> TEST check or so which checks the iface against some NM state, and
> then set ID_NM_OWNED_AND_OPERATED=1 or so). Then, ship a .link file
> (or multiple) with a Property= match in the [Match] section, that
> sets
> the desired policy.

ID_NM_OWNED_AND_OPERATED=1 would be nice and have general uses, outside
this dicussion.

If we had such a property we could tell the user to drop their own
.link file to adjust the udev configuration to what they want,
specially targeting NetworkManager devices. But it's not clear they
really need this. Link files already have plenty of matching
capabilities, so they probably could sufficiently just match on the
name.

Nice feature in theory, but the actual usecases so far were not strong
enough to implement it. Patch welcome!

> 
> With such a logic, NM could make its own choices on MAC policy, but
> the default systemd policy wouldn't have to change.
> 
> Also, afaik OSes that run in clouds all have some tool like cloud-
> init
> or ignition or so, which generate .network files in /run with the
> right
> configuration. Why not generate .link files in /run the same way with
> a MAC policy appropriate for the cloud provider?


best,
Thomas