On 7/15/25 15:51, Thomas Lamprecht wrote:
> Am 15.07.25 um 14:30 schrieb Stefan Hanreich:
>>>> 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.
> That would be certainly nice to have for admins, but it would also
> be nice if firewall stack can still transparently cope with the altnames.
It can - with the patches included in this series.
> btw. a reboot in the "pinned but not applied" state might need some
> special handling to, because IIRC it would now apply the /e/n/i changes
> but not the firewall rules.
> We could add the handling for the node firewall rules in the apply /e/n/i
> endpoint, as then it might work automagically?
I can look into that, then this might be the best way forward, if I can
move it there easily.
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
