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