Re: [pbs-devel] [PATCH backup] fix #3336: cleanup when deleting last snapshot

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 10/03/2025 16:22, Shannon Sterz wrote:
> On Mon Mar 10, 2025 at 4:19 PM CET, Fabian Grünbichler wrote:
>>> Wolfgang Bumiller <w.bumiller@proxmox.com> hat am 10.03.2025 11:53 CET geschrieben:
>>> On Fri, Mar 07, 2025 at 04:53:14PM +0100, Shannon Sterz wrote:
>>>> On Fri Mar 7, 2025 at 4:33 PM CET, Wolfgang Bumiller wrote:
>>>>> On Fri, Mar 07, 2025 at 11:37:32AM +0100, Shannon Sterz wrote:
>>>>> IIRC we need to figure out a good upgrade strategy so running processes
>>>>> don't use different locking.
>>>>>
>>>>> One idea was to have the postinst script create a file in run (eg
>>>>> `/run/proxmox-backup/old-locking`) which, when present, instructs the
>>>>> daemons to keep using the old strategy.
>>>>>
>>>>> The new one would then automatically be used after either a reboot, or
>>>>> manually removing the file between stop & start of the daemons.
>>>>
>>>> yeah i remember that being a blocker, but since pbs 4 is coming up
>>>> soon-ish, couldn't we just apply it then? upgrading between 3 -> 4
>>>> requiring a reboot seems reasonable to me, though maybe i'm missing
>>>> something (e.g. could it be problematic to have the services running,
>>>> even shortly, before the reboot?).
>>>>
>>>> if that would be an option, it'd be much simpler than carrying around
>>>> that switching logic forever (or at least one major version?). also,

One major version would be enough for all practical cases as we require
a reboot for the new kernel after an upgrade, which ensures that no old
PBS processes are around anymore as side effect. So people staying on EOL
version for a while and then do two major upgrades in quick succession
without any reboot are a bit on their own anyway, adding a hint to the
upgrade docs for that case would be cheap though and cover those admins
that actually try to do a good job and are just fixing such an outdated
setup without having been the one that caused it to exist in the first
place.

>> I don't think that works, unless we want to require putting all datastores
>> into maintenance mode prior to the upgrade and until the system has been
>> rebooted?
>>
>> otherwise, the upgrade from 3.x to 4.x is just like any other, with all the
>> same problems if the old proxy still has a backup or other lock-holding task
>> running and the new one uses different locking..

That's what the flag is for, touch it on upgrade before the new daemon
starts, in the new daemon set an internal global OnceLock (or the like)
guarded flag and use that to determine if old or new locking needs to be
used. On the next reboot the flag won't be there anymore and thus new
locking mode is used.


> i feel like it would be fine to do that though? we already optionally
> recommended that when upgrading from 2 -> 3 [1]. so requiring that and
> documenting it in the upgrade notes sounds fine to me.
> 
> [1]: https://pbs.proxmox.com/wiki/index.php/Upgrade_from_2_to_3#Optional:_Enable_Maintenance_Mode

can be an option, but not requiring user doing this is always nicer for
them and our support.


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel