On 7/14/25 16:31, Thomas Lamprecht wrote:
Am 14.07.25 um 15:53 schrieb Dominik Csapak:
On 7/14/25 15:49, Christoph Heiss wrote:
Tested the series, came across two thing:
Given e.g. the following interface:
11: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc [..]
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff
altname nic8
altname enxdeadff02d073
and the following /etc/network/interfaces snippet:
auto nic8
iface nic8 inet manual
the interface will be displayed twice in the network page. If in the
above snippet s/nic8/ens8/ is done (i.e. using the primary name), it
works correctly.
I guess between our /e/n/i parser and the altname mapping the interface
is picked up twice, so this will need some sort of "de-duplication" in
the backend, from what I can gather.
yeah i don't touch the which interfaces will be shown, so
that's on the /e/n/i parser
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
* having any custom altname in the /e/n/i would require the computed/shown
altnames to be
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
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'....
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')
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
