Proposal: enable stateless persistant network interface names

[Thomas Goirand]

On 05/11/2015 05:53 AM, Marco d'Itri wrote:
> On May 08, Martin Pitt <mpitt at 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)