Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Lennart Poettering]

On Wed, 23.01.13 15:26, Matthew Miller (mattdm at fedoraproject.org) wrote:

> On Wed, Jan 23, 2013 at 07:59:07PM +0000, Jaroslav Reznik wrote:
> > The udevd service has a long history of providing predicatable names for
> > block devices and others. For Fedora 19 we'd like to provide the same for
> > network interfaces, following a similar naming scheme, but only as
> > fallback if not other solution such as biosdevname is installed or the
> > administrator manually defined network interface names via udev rules or
> > the old network scripts.
> [...]
> > This feature is about enabling this as default in Fedora, but only as a 
> > fallback if the user/administrator did not manually assign names to interfaces 
> > via udev rules, or via the old networking scripts, or if biosdevname is 
> > installed.
> 
> This seems to invent yet another new naming scheme. We just went through
> this pain, and the biosdevname scheme went through several iterations in the
> field and represents real-world lessons learned. Is there a compelling
> reason to make the systemd/udev policy for Fedora not just follow the
> existing solution to the same problem embodied in biosdevname? (Then, we
> could just phase out biosdevname.)

Yes, because biosdevname bases its names partly on the enumeration order
of things, for the sake of "pretty" names. However, the enumeration
order is dependent on system state, and might change when the system
changes. i.e. instead of sticking to topology information that is an
inherent, stable and fixed property of the devices themselves it
invented its own numbering scheme, that is based on properties,
configuration and state of the full system. But in order to establish
predictable, stable names, regardless in which state your system is,
regardless which hardware is currently around, plugged in, probed, and
regardless in which order it got added, plugged in and probed, you
really don't want to base your naming scheme on the enumeration order,
and invent your own naming scheme.

The udev naming scheme systemd/udev 197 introduced and which this
feature is about only uses physical properties that are local to the
devices. That sometimes has the negative effect that the names are not
as pretty, but they are guaranteed to be strictly predictable and
stable: regardless in which order the kernel probes this hardware,
regardless if the user updates the kernel or drivers, or any userspace
packages, regardless if the user adds/removes hardware, regardless if
the boot is fully parallelized and fast or slow and serialized.

That inventing your own numbering is a problem manifests itself in bugs
like this:

https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21

> Also, I strongly question this line in the Feature page:
> 
>   "Users generally won't see this, as interface names are not exposed in
>    high-level UIs."
> 
> This is simply not true for many values of the word "user" which we support
> in Fedora, which runs right into the drawback mentioned in the upstream
> documentation:

Well, the page says "high-level UIs". The GNOME3 UI certainly doesn't
expose the interface name anywhere, does it?

But I guess we simply have a different definition of a user here. Your
definition is probably closer to what the page calls "admins", which is
covered by the next lines in the feature page, which you didn't paste:

"As biosdevname is installed by default ...  most administrators won't
see this either. "

Lennart

-- 
Lennart Poettering - Red Hat, Inc.