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.
>
> 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?
That doesn't seem to work currently, since pvenetcommit [1] simply moves
/e/n/i.new to /e/n/i. The current dependency tree of that service also
would make changing the order quite awkward, if we simply wanted to
invoke the reload_network_configuration API endpoint.
We could implement a small perlscript, that gets executed by
pvenetcommit, which would invoke the reloading logic contained in the
apply endpoint as an alternate solution? This would then apply the SDN /
FRR config on restart as well. This would be required anyway though,
since we potentially change the SDN controller config as well.
[1]
https://git.proxmox.com/?p=pve-manager.git;a=blob;f=services/pvenetcommit.service;h=19b2f1431d3810e4f64dc0f32fe0577e954e3e89;hb=HEAD
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
