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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
