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

[Fabian Grünbichler]

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.