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 DCC531FF16B for ; Tue, 15 Jul 2025 09:41:25 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 240743519A; Tue, 15 Jul 2025 09:42:22 +0200 (CEST) Message-ID: <15def8ea-87cd-4800-bcd3-808920be2deb@proxmox.com> Date: Tue, 15 Jul 2025 09:41:49 +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> Content-Language: en-US From: Dominik Csapak In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.022 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" 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: 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