[pve-devel] [PATCH pve-manager 1/1] cli: add pveeth

[Stefan Hanreich]

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 at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 
>