From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 4F3401FF16B for ; Tue, 15 Jul 2025 11:00:22 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D78F736918; Tue, 15 Jul 2025 11:01:18 +0200 (CEST) Message-ID: <881f2d84-5f0b-426d-b440-00ce893f68cd@proxmox.com> Date: Tue, 15 Jul 2025 11:00:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Thomas Lamprecht , Proxmox VE development discussion , Christoph Heiss References: <20250714104235.2107690-1-d.csapak@proxmox.com> <15def8ea-87cd-4800-bcd3-808920be2deb@proxmox.com> <5e6c851c-a621-407a-8740-019624e05f14@proxmox.com> <7a91c329-0faf-446e-a23c-21cb817d63ba@proxmox.com> <2b2ba728-7699-4423-96c5-8a7528ed8c93@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <2b2ba728-7699-4423-96c5-8a7528ed8c93@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_MSPIKE_H2 0.001 Average reputation (+2) RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager/widget-toolkit 0/2] show altenative interface names in the web ui X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox VE development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" 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