On Di, 05.07.22 22:35, Dusty Mabe (dusty@xxxxxxxxxxxxx) wrote: > On 6/25/22 15:06, 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. > > Based on the feedback here on the list we have modified the scope of this proposal > to now be limited to changing the MACAddressPolicy=none for bond/bridge/team devices only. > > New summary: > > ``` > The systemd-udev package installs "/usr/lib/systemd/network/99-default.link", which sets Link.MACAddressPolicy=persistent for all software NIC devices. This proposal is to add to the policy so that we use Link.MACAddressPolicy=none for bond/bridge/team devices. > ``` > > https://fedoraproject.org/wiki/Changes/MAC_Address_Policy_none So, with changing this back you'll also break all those setups where it is assumed the bridge MAC just works and is stable and independent from the devices added to it and the order in which they are added in. What makes you so sure, that changing this *again* is so much better than just leaving it the way it is now? This change isn't precisely new, and changing stuff forth and back comes at quite a price. Generally, if we change behaviour like this, then the pros must seriously outweight the cons. Now you might argue that when the original change was made that wasn't the case, that's a valid opinion, though one I disagree with. But that has no effect on today, on the question whether changing it again is worth it. I am pretty sure that there are *also* numerous scripts that benefit from the predictability and stability you get with the status quo, and which you'll break if you revert to the old state – again. I am not convinced we should flip flop on this all the time. Yes, it's unfortunate that people tripped over this, but you are not really making it better if you then break it *again*, given the benefit is unclear, and the major software creating bridges/bonds/… doesn't care anyway (i.e. NM, networkd, …). I for one do not see where you'd get the crystal ball to look into to know that by changing this *again* you'll make bazillions of people happy, and only very few people sad, because you break their stuff. It might very well be that you'll make more people sad because you break their stuff again, than were happy before. Also, let's not forget that allowing users to set the policy is a good thing, we should let them. Given that the original change was already made a lot of software that cannot work with such changes has already been updated to override the default policy. That's a good thing, since the overall system becomes more robust and people can more safely change the policies locally, with less breakage to expect. if you now revert to the status quo ante, then you basically also say: fuck it, we don't care that software is fixed to work with changed policies, let's keep things brittle that you cannot change policies anymore effectively because we are sticking our head in the sand and don't care that they are fixed. So, I am not convinced. I can accept that this wasn't handled particularly nicely originally. My proposal for addressing this is via documentation, i.e update the udev and iproute docs to explicitly point to the issue and how to deal with it, with an example drop-in to make it easy to deal with it. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
