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

Wolfgang Bumiller w.bumiller at proxmox.com
Fri Aug 12 16:31:38 CEST 2016


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.




More information about the pve-devel mailing list