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
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
