[pve-devel] [PATCH] Add support for custom storage plugins

[Wolfgang Bumiller]

On Fri, Aug 12, 2016 at 04:07:07PM +0200, Fabian Grünbichler wrote:
> On Wed, Aug 10, 2016 at 03:44:02PM +0300, Dmitry Petuhov wrote:
> > 10.08.2016 14:58, Dietmar Maurer пишет:
> > > This is by intention - we want people to use open source software.
> > ``Use open source software'' and ``patch Storage.pm on every update'' are
> > little different things.
> > 
> > Users are still free to share their code if it loads automatically, but
> > autoload eases life if plugin if actively used, but not being included into
> > PVE distrib for some reason.
> 
> I see the point - but there would need to be some additional changes for
> this to be accepted in my opionion:
> 
> - there needs to be a way to output loaded plugins (for support / bug
>   triage, because loading third-party plugins would need to be
>   completely unsupported)
> - there needs to be some kind of storage plugin API version mechanism to
>   disable loading of outdated/incompatible plugins (and storages using
>   those plugins)
> 
> since all the existing supported storage plugins are part of one git
> repository and one deb package, the latter was not needed so far. but if
> such an autoloading mechanism were to be included, there would be a lot
> of automatic breakage whenever the supported plugins get a new
> method/new method parameter/return type change/.. which is used by
> PVE::Storage, but no corresponding update was made to the third-party
> plugin. such changes could then bump the minimum required API version in
> PVE::Storage, and the plugins would need to have a corresponding
> "implemented API" version.
> 
> this does of course imply that the API is backwards compatible (i.e., a
> newer plugin works with an older PVE::Storage), which might require a
> cleanup of the existing plugins first.. which kind of returns us to
> square one - do we want to do this additional work for something which
> is essentially unsupported and whose main beneficiaries are proprietary
> storage solution vendors (and their users)? I am not yet convinced that
> this is something that I want to spend a lot of time and effort on, but
> I am not opposed to merging such changes.

A simple check that the plugin's ->api_version() is == the current
version would be fine IMO. If it changes, plugins have to be adapted.
Not investing time in backward compatibility is an option after all ;-)

Storages for which the plugin cannot be loaded would then simply
disappear, which is fine. Better than data corruption due to an
incompatible API for sure.