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