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 CAE5A1FF16B for ; Tue, 15 Jul 2025 15:47:01 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A42653E173; Tue, 15 Jul 2025 15:47:58 +0200 (CEST) Message-ID: <31451f01-06de-4cdb-a860-667ec4551b21@proxmox.com> Date: Tue, 15 Jul 2025 15:47:54 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Thomas Lamprecht , Proxmox VE development discussion , Dominik Csapak References: <20250715090749.1608768-1-d.csapak@proxmox.com> <20250715090749.1608768-3-d.csapak@proxmox.com> <1f39b2d5-4c02-44fd-aabb-2e0a585547f3@proxmox.com> <2dd7d909-fdfd-42e9-a47c-c9c04c4a8891@proxmox.com> <64d42fb0-77de-4803-96b6-da72574daab9@proxmox.com> Content-Language: en-US From: Stefan Hanreich In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.676 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) 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 pve-manager v2 1/1] api/ui: show/return alternative interface names 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" On 7/15/25 15:15, Thomas Lamprecht wrote: > Am 15.07.25 um 15:08 schrieb Stefan Hanreich: >> On 7/15/25 14:36, Thomas Lamprecht wrote: >>> but what changes are there required if it's _transparent_ altname support? >> >> We would refer to the newly generated, pinned, names then in the >> configuration files. > > That can be done when serializing those out the next time they get > written though? IMO there's not much benefit for adding such a big > churn, that's only asking for trouble with no advantage for all users > that do not manually edit the firewall rule (or SDN) configs, and > that would still work, it just might be slightly confusing at first; > but the latter can be defused by mentioning this explicitly, e.g. in > documentation about pinning and maybe a CLI stdout message in the tool. But if the (alt-)name of the NIC changes in the meanwhile and the configuration doesn't get written inbetween, how would we ever be able to infer which NIC was initially referenced in the configuration file? Isn't this the exact case we're trying to solve with pinning? Or am I misunderstanding something here? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel