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

[Eric Blake]

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?

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?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20131031/fdfa7f44/attachment-0001.sig>