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

[Dominik Csapak]

On 7/15/25 10:17, Thomas Lamprecht wrote:
> Am 15.07.25 um 09:41 schrieb Dominik Csapak:
>> On 7/14/25 16:31, Thomas Lamprecht wrote:
>>> Fwiw, it's not really wrong, one is the name in /e/n/i and the others
>>> are interface names per `ip link`, but it naturally can be a bit
>>> confusing as is.
>>>
>>> Depends also a bit on what we want, i.e., it probably makes sense to always
>>> show the name used in the /e/n/i config in the name column, and always filter
>>> that out from the alternative names displayed, as that allows the easiest
>>> correlation to the /e/n/i config, which is the main source of true for this
>>> panel.
>>> The small downside for that is then that the Alternative Names column is not
>>> a 1:1 mapping of what `ip link` shows as altname, but that probably is not
>>> an actual issue, after all they all live in the same namespace and are
>>> interchangeable for usage with the iproute2 tools.
>>> But that might also mean that we have to treat duplicates explicitly here
>>> in the API call enhancing that info. Waiting until tomorrow makes sense in
>>> any way though, as Stefan will be back from his short vacation then and
>>> might have some input here.
>>
>> i thought a bit about this, and I think there are some disadvantages when
>> just taking the names from /e/n/i:
>>
>> * not sure if it would work at all (depends on ifupdown2), but some
>>     weird configs could make the ui even more confusing, e.g. (assuming nicX is an altname of nicY):
>>
>>           auto nicX
>>           iface nicY inet manual
>>
>>
>>     we now would probably pick up both nicX and nicY, and show both in addition to what ip link says
> 
> Just test it? I'd like to avoid theoretical conversations, this can be
> already confusing enough without that. In anyway, we can normalize that
> on serialization and it's a edge case the user had to manually cause
> themselves, so would not bother to much at all with this case.
> 

yeah, sure. just wanted to write down my thoughts before doing further work

>>
>> * having any custom altname in the /e/n/i would require the computed/shown altnames to be
> 
> What does "custom altname" mean?

i just meant altname instead of what ip link reports as default (sorry for the confusing wording)

> 
>>     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

> 
>> Disadvantage is of course that for some this might be more confusing as some will be
>> taking /e/n/i as a reference and not 'ip link'....
> 
> Yeah, and ip link shows all names, /e/n/i has normally just the one
> name, so one can easily map any /e/n/i variant to ip link but not vice
> versa.
> 
>>
>>
>> I don't think there is a good way to make it super clear for all situations/users, but in the end
>> we have to decide what is the 'ground truth' (i.e. either /e/n/i or 'ip link')
> 
> Writing this I'm a bit more certain about:
> 
> "iface" entries are our source of truth and the name from POV of the API
> and UI, outdated "auto" statements can be fixed on serialization and also
> normalized on parsing, they can only stem from manual editing and are not
> a real issue.
> All other names pointing to the same interface should be picked up as
> alternative names.
> 
> And if we want to highlight the primary name ip link shows, this could be
> done either inline in the UI, or through by placing it in a dedicated
> column. Both could be followed up on depending on the user feedback we get,
> so I do not think we need to decide that now.
> 
> The /e/n/i config always was the source for the network config view–which
> isn't a network status view–so that should IMO really stick with /e/n/i as
> prime source of truth.
> 
> Seeing status of all interfaces  including statistics and the like might be
> nice, but that probably is handled as new API and component, potentially
> even a cluster wide one. There we could then make iproute2/kernel the primary
> source of truth, and only show any config name a interface is used as.
>   But I'd not think about this to much for the transparent altname support.

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