[libvirt] [PATCH v2] storage: vz storage pool support

[Olga Krishtal]

On 20/12/16 20:55, John Ferlan wrote:
>
> On 12/16/2016 06:14 AM, Olga Krishtal wrote:
>> On 08/12/16 22:56, John Ferlan wrote:
>>>>> Compare that to NFS, which uses mount which is included in well every
>>>>> distro I can think of. That's a big difference. Also let's face it, NFS
>>>>> has been the essential de facto goto tool to access remote storage
>>>>> for a
>>>>> long time. Personally, I'd rather see the NFS code split out of the
>>>>> *_fs.c backend, but I don't have the desire/time to do it - so it stays
>>>>> as is.
>>>> To sum this up, you still think that copy and paste isn't a problem here
>>>> and will create more value than do any harm, right?
>>>>
>>> Not sure what you're inferring by copy and paste - other than perhaps
>>> having to decide for the vstorage backend which storage backend API's it
>>> needs or should support.
>>>
>>> The list of API's as I see from the path are:
>>>
>>> +
>>> +    .startPool = virStorageBackendVzStart,
>>> +    .checkPool = virStorageBackendFileSystemCheck,
>>> +    .stopPool = virStorageBackendFileSystemStop,
>>> +    .findPoolSources = virStorageBackendVzfindPoolSources,
>>> +    .buildPool = virStorageBackendFileSystemBuild,
>>> +    .deletePool = virStorageBackendFileSystemDelete,
>>> +    .refreshPool = virStorageBackendFileSystemRefresh,
>>> +    .buildVol = virStorageBackendFileSystemVolBuild,
>>> +    .buildVolFrom = virStorageBackendFileSystemVolBuildFrom,
>>> +    .createVol = virStorageBackendFileSystemVolCreate,
>>> +    .refreshVol = virStorageBackendFileSystemVolRefresh,
>>> +    .deleteVol = virStorageBackendFileSystemVolDelete,
>>> +    .resizeVol = virStorageBackendFileSystemVolResize,
>>> +    .uploadVol = virStorageBackendVolUploadLocal,
>>> +    .downloadVol = virStorageBackendVolDownloadLocal,
>>> +    .wipeVol = virStorageBackendVolWipeLocal,
>>> +
>>>
>>> Other than startPool and findPoolSources, the code will reuse/call the
>>> virStorageBackendFileSystem* API's - so the only copy/paste would be
>>> copyrights, some #include's that would be required only for vstorage,
>>> the VIR_FROM_THIS definition, VIR_LOG_INIT...  Nothing any other backend
>>> wouldn't have to do.
>> By reusing you mean to export  virStorageBackendFileSystem* and call
>> them from
>> staorage_backen_vstorage?
>> Otherwise, may be I could do vstorage stuff only under #ifdef without
>> touching any of
>> virStorageBackendFileSystem* ?
> I can see why the desire is to use storage_backend_fs because it already
> has a bunch of things you'll need, so I understand why it's desired to
> be included there.
>
>  From the other POV though - the more #ifdef code in storage_backend_fs
> the 'harder' it is to separate things (conceptually).

Than I will move vstorage backend to separate file with the copy of 
virStorageBackendFileSystem*
and etc. And if the fs backend code will be splited or smth. - we will 
change vstorage backend accordingly.
> Finally, I also have floating around is the fspool adjustments and
> wonder what kind of overlap exists.

Let's not mix this fspool driver and backend for storage pool.
There is no overlap. At the moment I want vstorage to be a backend for 
storage pools,
so we can store images in there (raw, ploop, qcow, etc).

> Still seeing progress is good too and I guess unless I or someone else
> volunteers to split up storage_backend_fs.c into multiple backends (fs,
> nfs, dir, etc.) I guess we're stuck with what we have.
>
>
> John
>
>>> Although I do question "checkPool" - I would think for vstorage that
>>> should check if the environment is "available" somehow *if* you want
>>> pool autostart
>> Thanks, you are right.
>>> Also for stopPool the code will essentially call unmount. So is that
>>> "expected" for vstorage?
>> yes, just umount.
>>> Going through each API callout is how you'll be able to tell me/us that
>>> taking that path will work for the vstorage environment.
>>>
>>> John
>>


-- 
Best regards,
Olga