[pve-devel] [PATCH manager/widget-toolkit 0/2] show altenative interface names in the web ui

[Dominik Csapak]

btw. tested using

auto nicX
iface nicY

etc.

it works AFAICT, our parser picks it up as two different ifaces (which makes sense)
and writes out a seperate 'iface' stanza for nicX in this case the next
time it's edited... so fine i guess

On 7/15/25 10:54, Thomas Lamprecht wrote:
> Am 15.07.25 um 10:36 schrieb Dominik Csapak:
>> On 7/15/25 10:17, Thomas Lamprecht wrote:
>>>
>>>>      calculated for *each*, so e.g. if i have
>>>>       nicX, nicY and nicZ all point to the same device, we'd have to make the altname list generation
>>>>      more complicated
>>>>
>>>>
>>>> IMHO it would be ok to always show the 'canonical' name (whatever ip link/kernel says)
>>>> in the 'name' column and everything else in the 'altname' column regardless what is
>>>> configured in /e/n/i
>>>
>>> There is no real canonical name, there's a legacy name that might be
>>> called primary one, but as one can use the others transparently for it
>>> we really must not think to much into that terminology, it's as first
>>> class as the other names.
>>
>> i would interpret the name the kernel has (e.g. what is in /proc/net/dev) as the 'canonical name' ?
>> please correct me if i'm wrong about that though
> 
> Those files and folders will always use the legacy name with the
> stricter naming length limits for not surprising any older tool
> with the more flexible newer naming,
> 
> That's why legacy name might slightly the better term for these,
> but as they will stay basically forever it's probably not really
> useful to make that distinction either.
> 
> Most users won't do much directly with these files, and if they are
> likely to be a bit more experienced to figure out this distinction.
> Most users, even technical ones, will use iproute2 tools if they
> can avoid poking /proc or /sys and especially the less experienced
> one only will check /e/n/i and ip addr/link when they run into trouble,
> which is they main underlying reason I want to show the altnames in
> that config view, so that their live gets a little bit easier by seeing
> what "iface XYZ" stanza they will need to adapt independent of the (alt)
> name used. And as one can use all names with iproute2 already this has
> the nice side effect of adding feature parity and consistency with a
> side benefit of a smaller chance for broken upgrades on systemd naming
> scheme policy changes.
> 

thanks for clarification


> 
>> ok then we have to think about how to organize the altnames structure properly
>> otherwise it's a PITA to map from the name in the /e/n/i to all others
>>
>>
>> (this is all implementation detail of course, but does make a bit of a headache)
>> currently we have a hash with collections of 'altname' => 'what ip link reports'
>> but in the case we have altnames in the /e/n/i, we'd actually need the a list of names that are
>> equivalent, and that either as a list to search through, or duplicated for each iface name that it
>> can reference, so e.g.
>>
>>
>> if we have nicX, nicY, nicZ all alternatives to each other, now we have:
>> {
>>      'nicY' => 'nicX',
>>      'nicZ' => 'nicX',
>> }
>>
>> but we actually want something like this?
>>
>> {
>>      'nicX' => ['nixY', 'nicZ'],
>>      'nicY' => ['nicX', 'nicZ'],
>>      'nicZ' => ['nicX', 'nicY'],
>> }
>>
>>
>> because when we want to show the alternative names of e.g. nicY the first structure is a bit bad to
>> search through
>>
> 
> So we basically have to start with a hash of all names from /e/n/i as keys
> and an empty array, then go through the keys and values of the altname map
> and add every name (independnt of "primary" = key or "altname" one of the
> values for that entry where the /e/n/i name matches one of the keys or values.
> 
> fwiw, the API could already add more info if you want to future proof it
> w.r.t. putting a distinction between legacy/primary name and altnames.
> 
> {
> 
>     'e-n-i-name' => {
>          'primary' => '...',
>           'altnames' => ['...'],
>      },
>      ...
> }
> 
> That way we would be flexible with adapting the UI to user feedback while
> keeping the API as is. For now we could just merge all primary and altname
> with the e-n-i name filtered out in a renderer for the new column.


while that could work, i found an easier way (at least for my code) that
works with the current structure too (i'll send a v2 shortly)