[pve-devel] [RFC v1 pve-storage 0/6] RFC: Tighter API Control for Storage Plugins

Thomas Lamprecht t.lamprecht at proxmox.com
Fri Feb 7 08:17:15 CET 2025


Am 06.02.25 um 15:56 schrieb Fiona Ebner:
> There are no such strong reasons, but we didn't have such strong reasons
> last time either (IIRC changing snapshot parameter for export for btrfs
> or something like that). I thought we need to do that on any breaking
> change? We do have a few queued up already for the next reset. Hence my
> suggestion to do it for PVE 9 so plugin authors can adapt together with
> adapting for the new Debian release.

Yeah, last time caused some more fall-out than I expected, I have reduced
motivation to repeat that, especially as we grew quite a few more users
and also some new external storage plugins.

If nothing big comes up I'm fine with just keep increasing both VERSION
and AGE in lock-step as needed. If that becomes painful we should rework
our approach to be less sudden – we want short betas for $reasons, thus
plugin author do not get a long heads-up there at all – like e.g. using
a moving window to more gradually drop support for older versions, unlike
a full reset, ideally defining which will be removed already earlier (most
lenient would be a full major release, less might be fine, needs to be
thought out). We could use those two also to decide for what to warn and
for what to either output nothing or only very rarely some notice level log

We might also need to get a bit more strict with how we handle API breaks,
but as this is easier to adapt too as end-user are less likely to be
affected, as in, our UI still works, breakage happens normally at an
endpoint level instead of all or nothing like here with storage plugins,
which means likely breaking PVE interfacing with such storages completely,
which will not allow guests on those storages to run or backups to go
through, ...




More information about the pve-devel mailing list