Re: [PATCH] storage: implement rudimentary glusterfs pool refresh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/31/2013 03:23 AM, Daniel P. Berrange wrote:
>>
>> My next task - figuring out the use of glfs_open() to read metadata
>> from a file and determine backing chains.
> 
> NB, we don't want the src/util code to gain a dependancy on glusterfs
> RPMs. It is a very heavy weight package chain which cloud folks don't
> want us to pull in by default, hence my recent changes to RPM deps.

Indeed; which is why I'm thinking that the src/util code has to call
into the storage driver to ask if any registered backends can handle a
network file name.  Because we are modular, the ONLY use of glfs.h will
be in the backend; if the correct rpm is installed to provide the
gluster backend, then the network file can be decoded; if the rpm is not
installed, then src/util has no choice but to treat the file as raw.

I don't know if that means the libvirt-daemon-driver-storage needs to be
further split into multiple .so files across multiple sub-rpms, so that
a user can pick and choose which .so backends to install rather than
dragging in all dependencies for all backends.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]