Re: Should `MACAddressPolicy=persistent` for bridges/bonds/all-software-devices be reconsidered?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 09.05.22 19:27, Zbigniew Jędrzejewski-Szmek (zbyszek@xxxxxxxxx) 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.

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

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?

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.

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?

Lennart

--
Lennart Poettering, Berlin