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

[Fiona Ebner]

Am 07.02.25 um 08:17 schrieb Thomas Lamprecht:
> 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, ...

I just thought that in the context of a major release, many plugins will
need to adapt to the new underlying Debian environment and thus provide
new versions in any case. Doing breaking changes outside of a major
release bears bigger risk that users might miss new plugin versions
(e.g. installed the plugin once without configuring/checking for updates
later). With "full major release" which of the following do you mean:
1. deprecated in PVE N.x, dropped in PVE (N+1).x for the same x
2. deprecated in PVE N.x, still supported throughout PVE (N+1), dropped
with PVE (N+2).0

We also lose a little flexibility about how we can do breaking changes:
e.g. changing parameter order would require adding a new method,
changing the existing one to be a wrapper and then dropping the wrapper
at some point - not so bad I guess, but forces us to come up with new
names for those methods.

But I can see your point why a full APIAGE reset is bad and not doing
any is fine by me. The opt-in env-var or similar for deprecation
warnings seems like a good approach IMHO. Just need to communicate this
properly to plugin authors if we add it. The deadline for a breaking
change could then also be included in the warning message.