On 6/27/22 13:03, Thomas Haller wrote:
> On Mon, 2022-06-27 at 10:10 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> On Sun, Jun 26, 2022 at 12:36:14AM +0530, Vipul Siddharth wrote:
>>> This document represents a proposed Change. As part of the Changes
>>> process, proposals are publicly announced in order to receive
>>> community feedback. This proposal will only be implemented if
>>> approved
>>> by the Fedora Engineering Steering Committee.
>>>
>>>
>>> == Summary ==
>>>
>>> The `systemd-udev` package installs
>>> `"/usr/lib/systemd/network/99-default.link"`,
>>> which sets `Link.MACAddressPolicy=persistent`. This proposal is to
>>> change it to set `Link.MACAddressPolicy=none` to stop changing the
>>> MAC address.
>>> This is particularly important for bridge and bond devices.
>>>
>>> This change can either only apply to bridge/bond devices, or to
>>> various software devices. That is to be discussed.
>>
>> Hi!
>>
>> I already participated in the upstream discussion, so what I write
>> here will be a restatement to some extent, but with a look from the
>> side of Fedora specifically.
>>
>> The proposal has two variants: 1. just changing the policy to
>> MACAddressPolicy=none
>> or 2. limiting the change to bridge and bond devices.
>>
>> Re variant 1: MACAddressPolicy=persistent applies to all devices that
>> don't have
>> a hardware address. The proposal as written (blanket
>> MACAddressPolicy=none)
>> would change behaviour for all kinds of devices, incl. e.g. software
>> devices like veths, and cheap hardware devices without a fixed MAC.
>
> the proposal was only about software devices.
>
> The difference is that software devices are explicitly added by some
> tool (if we ignore module parameters like "max_bonds" -- which on
> fedora/systemd is already 0 by default).
>
> A hardware device gets automatically added when loading the kernel.
> More importantly, udev already does renaming, so any user is well
> advised to wait for udev to settles. At which point, they can also wait
> for the MAC address policy.
>
>
>> The proposal doesn't provide any justification for this (except for
>> simplicity of implementation) and this variant seems pretty bad and
>> I'm strongly opposed.
>
> The first point: the race. And that udev touches interfaces created by
> somebody, without being explicitly told to do so.
>
> Yes, udev always does something to the device, like attaching
> attributes such as ID_NET_NAMING_SCHEME. But aside the MAC address
> policy, it doesn't do anything relevant where a race would matter.
>
>>
>> Re variant 2: the proposal limited to brige/bond devices seems much
>> more
>> reasonable. In particular, the case described below of a server
>> (virtualized
>> or not) in a big datacenter is the one case where the benefits of
>> MACAddressPolicy=none are clearly visible. I still don't think it's
>> worth
>> changing the default, but here the cost:benefit ratio is much closer.
>>
>>> == Benefit to Fedora ==
>>>
>>> Pros:
>>>
>>> - Consistent behavior with RHEL8 and RHEL9.
>>>
>>> - Avoid race of udev and the tool that creates the interface.
>>
>> The race will happen if the creation is done in a specific way. But
>> at
>> the same time, even the Change proposal describes how to avoid the
>> race ('ip link add address aa:aa:aa:aa:aa:aa type bridge'). So the
>> situation
>> can be summarized as "we have a bunch of 'big' tools that create
>> devices like NetworkManager or systemd-networkd, which already know
>> or
>> can be easily fixed to avoid the race, and a manual tool which can be
>> invoked
>> in a way that avoids the race". Instead of changing the default in
>> udev we
>> could educate people how to invoke it better.
>
> I don't think that big projects matter much. They can learn this. For
> example, docker had a problem with this ([1]), which presumably got
> fixed long ago.
>
> [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/15#note_162509
>
> The problem are smaller projects and user scripts/tools.
>
> For example, NetworkManager-ci contains hundreds of scripts for
> testing, and -- while we should know better -- we don't wait for udev
> after creating a veth interface for testing. That is no problem for us,
> we just set MACAddressPolicy=none. But it makes me wonder, just how
> many "naive" scripts are out there that don't get this right.
At least for block devices, waiting for udev to finish can actually
be a non-trivial overhead, especially when udev has been explicitly
told to *not* do anything with the devices in question. It has a
measurable impact on how long LVM commands take to run, and LVM is
known to be a significant contributor to the amount of time Qubes OS
needs to start a VM.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
