[systemd-devel] Udev won't rename interfaces that are already UP

[Tom Gundersen]

On Thu, Feb 19, 2015 at 4:59 AM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> В Wed, 18 Feb 2015 21:48:48 +0100
> Tom Gundersen <teg at jklm.no> пишет:
>
>> On Wed, Feb 18, 2015 at 9:36 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>> > Am 18.02.2015 um 21:29 schrieb Giancarlo Razzolini:
>> >> It is my perception that if you are using predictable network interface
>> >> naming, which is the current default, you can safely make your network
>> >> configuration use the changed interfaces names to be sure they'll get
>> >> the desired interface. This applies to network configuration, firewall
>> >> rules, whatever
>> >
>> > predictable? go away!
>>
>> I think you know he was referring to:
>> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
>>
>> Maybe you disagree with the use of the word 'predictable', but that's
>> what the scheme is called, so let's just stick to that (maybe thinking
>> of it as 'deterministic' would make it more palatable).
>>
>
> What's wrong with renaming it if we agree that name was chosen
> badly^Wsuboptimal? Unless this is deliberate marketing decision of
> course.

I don't think there is anything wrong with the current name. Just
tried to give some extra explanation.

>> > on any machine i know running network.service (the old style)
>> > ethX is predictable and the new "predictable" changed multiple times and
>> > frankly there are configurations re-used on a dozens of machines where i
>> > know in case of *all of them* that eth1 is *always* the WAN interface
>>
>> Good. Then disable the logic. But please understand that in general it
>> is not possible to know whether eth0/eth1 will be switched between
>> reboots. Our default logic must work in general, not only on specific
>> machines, which is why it is the way it is.
>>
>
>
> Come on, persistent interface names, including topology based name
> assignment, was possible and in use long before this new scheme was
> invented.

Hm? So?

> New scheme is not about "predictability" but about removing
> need to rename interfaces.

The main point is to ensure that rebooting the machine does not change
the name of your interfaces.

> The only real justification is "trying to
> assign the interface name raced against the kernel assigning new names
> from the same "ethX" namespace". From user point of view it sounds "we
> (developers) were not able to solve this problem so we decided to make
> it your (users) problem".

That is a related problem, but it is a minor detail. The point is that
we don't want to have to store state on disk (about which interface
should have which name). The only way then is to find an algorithm
that will always compute the same name for the same interface without
referring to any state. Topology is one way. Firmware information is
another. MAC addresses is another. Using the kernel names as-is is out
of the question. Having a list on disk mapping interfaces to names is
also out of the question.

Anyway, it is super easy to disable this stuff, so if you don't like
it you can provide your own logic and just disable the default one (or
if you can come up with a better way of achieving stateless
determinism, I'm all ears).

Cheers,

Tom