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 4236D1FF16B for ; Tue, 15 Jul 2025 14:35:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B2DD23B0C8; Tue, 15 Jul 2025 14:35:55 +0200 (CEST) Message-ID: <8d89e19b-2c81-490b-ac20-5194144f1e89@proxmox.com> Date: Tue, 15 Jul 2025 14:35:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Stefan Hanreich To: Thomas Lamprecht , pve-devel@lists.proxmox.com, Gabriel Goller References: <20250709194526.560709-1-s.hanreich@proxmox.com> <20250709194526.560709-8-s.hanreich@proxmox.com> <3973bc97-151c-4dfc-b2ab-f9e781f1056a@proxmox.com> Content-Language: en-US In-Reply-To: <3973bc97-151c-4dfc-b2ab-f9e781f1056a@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.678 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 1/1] cli: add pveeth 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 14:30, Stefan Hanreich wrote: > On 7/10/25 18:25, Gabriel Goller wrote: >>>> However, unpinning has a problem. Currently, we reset to the >>>> `ID_NET_NAME_PATH` name from `udevadm` and remove the link file, but we >>>> don't know the current systemd `NamePolicy`. > > Not sure if users overriding the default naming policy of network > interfaces is a common enough use case to consider here. In that case > users will have to take care of updating / changing the network > interface names themselves anyway, since they would change with that > setting as well. > > >>>> For example, if the original interface was `ens18` using Slot policy, >>>> after pinning it becomes `nic0`. When unpinning, the interface becomes >>>> `ens18` again (because I'm using slot policy), but the config files >>>> reference `enp0s18` (because `pveeth` assumes we use path policy). This >>>> breaks the network configuration. >>>> >>>> I think the solution is to avoid deleting the link file during >>>> unpinning. Instead, we should just update the interface name. >>>> >>>> The problem is that we can't determine which policy was originally used, >>>> so pin-unpin cycles *don't* restore the original interface name. > > But then we'd have changed the name that we're pinning, not removed the > pinning altogether. > > Unpin is trying to revert to the name that would be automatically > generated without any link files present, not the exact name that the > NIC had when we generated the pinning. I can see how this might be > obtuse though, particularly since I write that pin / unpin should be -obtuse +obscure > idempotent (which they aren't, because of the behavior I described > above) - my mistake. > > With storing names there's still the possibility of the stored name > clashing with another interface in the meanwhile (due to e.g. upgrades). > We cannot just store the old names and reset to them. Even with the same > naming policy, names can change across updates (which is what happens > with the upgrade to systemd v257, for instance), so we have to query how > the interface name would look like with the *current* settings, not with > the settings at the time of pinning. This also applies to storing the > policy, who says that the policy hasn't changed since we stored it? > > >>> This I'd need to think through, just wanted to comment on above before >>> I forget. >> >> If we really want to make pin and unpin involutive, we would need to >> store somewhere the interface names or store the interface naming >> policy. > > unpin was more intended as a solution for users that made an error with > invoking the pin command and give them an easy way to revert the changes > generated by pin. In the other thread with Dominik I've also discussed a > different approach on how to handle applying the configuration. Solving > it as follows would also introduce a way of reverting the configuration: > > * 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. > > If we solve it like this, then we could introduce a 'revert' or > 'rollback' command, which would simply delete any pending changes and > then remove the generated link files. We'd have three possible actions > for handling pending configuration files: > > * generate (generates the pending configuration) > * apply (which applies pending configuration) > * revert/rollback (which removes any pending configuration changes) > > This would reset everything to the way it was before generating the > pending configuration. It would also obsolete a dry-run flag imo, since > we have the intermediate, pending, configuration that needs to be > manually applied. Users can use those for inspecting the potential changes. > > It would still make sense to provide the opportunity for users to get > rid of all pinned names, which unpin in its current state could then do. > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel