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

[Daniel P. Berrange]

On Thu, Oct 31, 2013 at 06:35:56AM -0600, 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.

The QEMU driver will need to use librbd to query backing file in any
qcow2 files stored in the rbd volume. Likewise for gluster. So while
making the storage driver modular would allow you to install a subset
of the storage driver deps, you're still not going to avoid pulling
in the gluster/rbd libraries, since the QEMU driver will pull them
in anyway.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|