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 CEC5D1FF187 for ; Mon, 14 Jul 2025 14:40:28 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 73CC7172DD; Mon, 14 Jul 2025 14:41:24 +0200 (CEST) Mime-Version: 1.0 Date: Mon, 14 Jul 2025 14:40:51 +0200 Message-Id: To: From: "Christoph Heiss" X-Mailer: aerc 0.20.1 References: <20250711162514.1929138-1-c.heiss@proxmox.com> <175225734250.3641728.12541357287409887038.b4-ty@proxmox.com> In-Reply-To: <175225734250.3641728.12541357287409887038.b4-ty@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.030 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_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] applied: [PATCH ifupdown2] d/patches: add patch for transparent handling of interface altnames 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 Fri Jul 11, 2025 at 8:09 PM CEST, Thomas Lamprecht wrote: > On Fri, 11 Jul 2025 18:25:12 +0200, Christoph Heiss wrote: >> tl;dr: add transparent altname support by caching links under their >> primary name as well as any potential altname, and translating all >> interface names from the config into the primary interface name. >> >> The structure makes it also as easy as possible to translate altnames in >> other corners of ifupdown2, if other cases should come up. >> >> [...] > > The amount of code changes are fewer than I expected, and most of it reads > pretty straight forward. While I'd expect a few bugs for edge cases to pop up, Yep, I don't completely rule some edge cases either, but I done a sanity check for other places where interface names are directly used - they are normally retrieved by looking up the interface index, which always returns the primary interface name. So overall it's the manually specified interface names that are problematic, thus the actual fallout/bugs should hopefully be pretty constrained. > the underlying design is IMO sound and a bit of testing of common stuff did not > surface any issues. > > So, applied, thanks! > > Once the (release) dust settles it might be still worth to send a PR upstream, > even though upstream went a bit silent, it still might help others and one > never knows what wonders might happen ;-) For future reference: https://github.com/CumulusNetworks/ifupdown2/pull/330 > > W.r.t the ports-condone-regex: I think keeping the current behavior is fine > for now, these attributes are not that wide spread and if they really just > affect reloads it won't trigger immediately after the first reboot after the > major upgrade, which is when the interface renaming is normally happening, so > admins get a chance to update these regexes then. > If we want to check them too the only sensible solution (without thinking this > through _that_ much though) would be to check if any of the interface names > match the regex, and if, ignore the respective interface. Alright, then I'd really just keep the current behavior for now, waiting for a real usecase to pop up. At least I have never seen any -condone-regex in any real-world /e/n/i, it really seems like a niche and/or rather Cumulus-specific feature. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel