Re: Proposal: enable stateless persistant network interface names
On 05/11/2015 05:53 AM, Marco d'Itri wrote:
> On May 08, Martin Pitt <mpitt@debian.org> wrote:
>
>> I propose to retire [mac], i. e. drop
>> /lib/udev/rules.d/75-persistent-net-generator.rules and enable
>> [ifnames] by default.
> I see a large enough consensus about switching by default to ifnames,
FWIW: I don't. In this very thread, I have read many counter-arguments.
> and I believe that the few people who want MAC-based names for USB
> interfaces can easily set NamePolicy=mac or write a custom rule.
As always (and as it was for systemd), what counts here is the default.
>> So we can only let time and replacing/reinstalling machines take care
>> of this. /etc/udev/rules.d/70-persistent-net.rules requires zero
>> maintenance from us (it's just like the admin had manually set their
>> own rules).
> Actually it requires us to keep maintaining the
> Revert-udev-network-device-renaming patch as long as there will be
> systems with a 70-persistent-net.rules file renaming eth* to eth*.
The other solution would be to upstream that patch (maybe as a kernel
option if that is relevant).
> I believe that firmware-based device names work well enough in practice
> since RHEL 7 uses them by default: I tend to trust a market-based
> approach to maintenability more than anecdote from a very selected
> population like the debian-devel@ subscribers.
Oh, how nice is that... So our opinions don't count, and Red Hat is just
always right!
FYI, I had non-anecdotal very bad experience to report, with the ifnames
from udev causing not-so-easy to fix issues deploying OpenStack on a
variety of hardware. I'm talking about large deployments here (in my
mind, large means more than 200 machines...).
> This is the relevant documentation, which I strongly recommend everybody
> interested in this issue to read:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Device_Renaming_Procedure.html
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Understanding_the_Predictable_Network_Interface_Device_Names.html
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html
All from redhat. /me not surprised...
> Maybe biosdevname would be nice to have, but:
> - somebody needs to actually maintain it in Debian
> - by default it only works on Dell systems
> - it is not loved by the udev/systemd upstream maintainers
> - it does not seem to me to provide any benefit over the firmware-based
> names since in practice both would use by default an interface index
> in the common case
>
> So I do not think that we need to care about it.
>
> An obvious downside is longer names for devices which do not provide
> ID_NET_NAME_ONBOARD: e.g. the WiFi card in my Dell laptop does
> not (wlp2s0), but the Ethernet port does (eno1).
> It will be even worse when not even ID_NET_NAME_PATH is defined (e.g. on
> my Allwinner-based ARM computer), which means that interfaces will get
> a mac-based name like enx028909xxxxxx.
Which is so convenient to type on the shell, right? :)
> But if somebody cares about the aesthetic value of network interface
> names then they can probably write a custom udev rule to rename them,
> or keep using 75-persistent-net-generator if we can keep it around.
So your proposal is: if the default is unusable (like above), then the
poor user has to find a way to fix that... I'm not convince that this is
what we want. I'd very much prefer a usable default.
Cheers,
Thomas Goirand (zigo)
Reply to: