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 AA70A1FF16B for ; Tue, 15 Jul 2025 12:32:25 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A0DC738F22; Tue, 15 Jul 2025 12:33:21 +0200 (CEST) Message-ID: Date: Tue, 15 Jul 2025 12:33:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Stefan Hanreich , Proxmox VE development discussion 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> Content-Language: en-US From: Dominik Csapak In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.021 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [i.new] 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-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/15/25 11:41, Stefan Hanreich wrote: > On 7/15/25 11:30, Dominik Csapak wrote: >> On 7/15/25 11:21, Stefan Hanreich wrote: >>> Was formulating my response to v1, but you were too fast with sending a >>> v2 for me. I think we need to also consider the case where we pinned and >>> replaced the names in /e/n/i via pveeth already, but the changes to the >>> network interface names haven't yet been applied. The problem here is >>> that we also return interfaces contained in /proc/net/dev in the >>> overview as well [1] - which would lead to duplicate interface names in >>> the view. >>> >>> I considered applying the changes to the network interface names >>> immediately via `udevadm trigger`. Alternatively, I thought of adding >>> the old names as altnames when pinning network interfaces, but not in a >>> persistent manner. I think both would solve this state between >>> transitioning from the old names to the new names. What do you think? >> >> >> ok, so from what i can tell 'pveeth pin' writes directly into the /e/n/i >> file? >> shouldn't it write to /e/n/i.new file (or whatever it's named) so we >> show it as pending change? > > Currently yes, but I am still considering what would be the best way > forward. I think you could make an argument for both. The problem is > that while we have this mechanism of a temporary configuration file for > /etc/network/interfaces and SDN, we do not have one for the firewall > configuration. There is a dry_run functionality in pveeth, but it just > generates the files in a different location. > > It might make more sense to implement it as a two-step process: > > * Pinning generates the new configuration files in the pending config of > /e/n/i and SDN. For the firewall we'd have to create one as well and > probably just handle this manually in the following step. > > * Add another command that applies the temporary changes which would > also include applying the changes via udevadm immediately. > > Then users could inspect the generated changes via our UI (at least for > Network / SDN). This would then also allow us to remove the dry_run > functionality, since it would be implicitly included in this create / > apply process. It would also solve the issue with this weird limbo state. > > I'm just unsure on how we could integrate showing the changes to the FW > configuration in a nice way. mhmm on the spot i'd probably say we could color code the fw rule changes (e.g. yellow for pending changed, red for pending removed, etc.) maybe also a seperate column with that info as text/symbol > >> then we could do the udevadm trigger in the 'apply config' api handler? >> >> also, basically the 'altname' lookup code would also have to lookup the >> .link files ? (seems like it's a lot of work/disk reading to do?) > > Yes, exactly - hence why I considered adding them as an altname since > this would save us this procedure of parsing *all* link files in order > to be able to generate a sensible view of /e/n/i. ah ok, so you'd do 'ip link property add dev ensX altname nic0' ? that way you could immediately add that too for the new name, no? when you'd do that, we would not need to parse the link files in the api code, since ip would already have that info ? _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel