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

[Daniel P. Berrange]

On Thu, Oct 31, 2013 at 12:46:07PM -0600, Eric Blake wrote:
> On 10/31/2013 12:34 PM, Daniel P. Berrange wrote:
> 
> > 
> > IIUC, this is still going to be introducing a direct code path dependancy
> > between the QEMU and storage driver code though.
> 
> No, src/qemu would still get backing chain details via src/util, the way
> it has always done.  Only src/util has to have the magic to call into
> src/storage backends (if the right backend is present, chase the backing
> chain of the network disk; if absent, forcefully assume raw as is
> already currently done).
> 
> > 
> > Currently src/qemu depends only on code in src/util & src/conf[1]. For
> > the storage pool bits, it can call indirectly via src/libvirt.c APIs, but
> > it does not call anything in src/storage/ directly. I really want this
> > to remain that way, because avoiding direct calls is key to enabling
> > us to split libvirtd up into separate daemons per driver in the future.
> > 
> > Daniel
> > 
> > [1] Yes, there's a dep on src/network too, which i was never at all happy
> >     about, and which needs to be refactored / removed in some manner in
> >     the future
> 
> This is a useful discussion, because I don't want to be developing code
> that violates layering constraints.  So, am I on the right track by
> allowing src/util to call into src/storage backends, or is the only
> proper way to do that to have src/util call in to src/libvirt.c APIs
> which then call into src/storage indirectly?

src/util shouldn't have any compile time dependancy on src/storage,
or indeed any other directory.

You could conceivably do it indirectly, by having src/storage
register some kind of plugin with src/util at startup. That way
it is only a runtime dep.

> How does this compare to src/qemu/qemu_process.c, using
> conn->secretDriver->secretGetValue(,
> VIR_SECRET_GET_VALUE_INTERNAL_CALL), as a means of calling into
> src/secret indirectly but without going through src/libvirt.c API?

Again, that's a runtime only dep. So if the libvirt_driver_secret.la
was not installed, it would not be fatal - the API calls would just
get a runtime error.

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 :|