[pve-devel] [PATCH v2 storage 4/5] disk reassign: add not implemented yet message to storages

[Fabian Grünbichler]

On September 3, 2020 11:06 am, Aaron Lauterer wrote:
> sent to early without finishing the last sentence...
> 
> On 9/3/20 11:01 AM, Aaron Lauterer wrote:
>> 
>> 
>> On 9/3/20 9:58 AM, Fabian Grünbichler wrote:
>>> wouldn't it make more sense to implement it in Dir/NFS/CIFSPlugin, and
>>> add this 'implement me' into Plugin itself? otherwise this breaks
>>> external plugins. also, would it make sense to add a feature for this so
>>> that we can check in the calling code with a meaningful error message
>>> before attempting and die-ing?
>> 
>> The storage plugins are a bit of a mess hierarchically. The base plugin (Plugin.pm) implements quite a few methods for the dir based plugins (dir, nfs, cifs) like `find_free_diskname` for example.
>> The other plugins overwrite these methods.

I know. most of that predates external plugins though ;) for new stuff, 
we should not pile on top of the mess.

>> 
>> If we want to do it properly and to avoid code duplication, we should probably add another class in between to which me move the common file based operations which are used by all the dir based plugins.
>> 
>> Plugin.pm
>>      BaseDirPlugin.pm
>>          DirPlugin.pm
>>          NFSPlugin.pm
>>          CIFSPlugin.pm
>> 

might a be a good idea, but would be a breaking change as you indicate 
below (so maybe 7.0 material?)

>> 
>> Having the reassigning as additional feature sounds good. I will try that. But this will need
> But this will need the intermediate dir base class so that we can add the feature just for them and not all plugins, especially third party ones which we cannot update.

you could also just refactor volume_has_feature (e.g., by splitting out 
the $features hash so that plugins can override it without fully 
overriding volume_has_feature), or override it with just that feature 
check and fallback to the base one otherwise.

> Then again, what if a third party plugin is using the dir based methods in the plugin.pm already?
> should I just add new things to the intermediate BaseDirPlugin in order to stay compatible?

that would be a possibility, and then move all the existing non-generic stuff at 
some later point when we need/want to break API anyhway.