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

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.