From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 54A951FF16B for ; Tue, 15 Jul 2025 13:06:20 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 586C6399F2; Tue, 15 Jul 2025 13:07:16 +0200 (CEST) Message-ID: Date: Tue, 15 Jul 2025 13:06:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Dominik Csapak , 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: Stefan Hanreich In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL 0.677 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-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 12:33, Dominik Csapak wrote: > 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 Yeah, I'll have to check how complicated that would be to implement - particularly when the two firewall rulesets start to diverge. But having a temporary firewall configuration similar to how /e/n/i or SDN works, was something that we wanted to explore anyway - so that could actually be a good starting point for that. >> >>> 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 ? > Yes, that was one of the solutions I had in mind, and that would be quite convenient for that case if we do not immediately apply the changes. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel