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

[Jim Fehlig]

Eric Blake wrote:
> 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.
>   

Just earlier this week I considered this approach while investigating an
internal issue.  In an older base product, we don't support rbd (and
hence the rbd backend), but an add-on product does support rbd.  We
discussed a "libvirt-daemon-driver-storage-backend-rbd" subpackage that
could included and used by the add-on product without affecting the base
product.

Regards,
Jim