Re: [libvirt] [RFC PATCH 0/7] Adding 'config' driver

On Mon, Jan 20, 2014 at 11:27 AM, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: > > On Fri, Dec 20, 2013 at 11:03:53PM -0500, Adam Walters wrote: > > This patchset adds a driver named 'config' that allows access to > > configuration > > data, such as secret and storage definitions. This is a pre-requisite > > for my > > next patchset which resolves the race condition on libvirtd startup and > > the > > circular dependencies between QEMU and the storage driver. > > I vaguely recall something being mentioned in the past, but not the > details. Can you explain the details of the circular dependancy > problem that you're currently facing ? > > > The basic rationale behind this idea is that there exist circumstances > > under > > which a driver may need to access things such as secrets during a time > > at > > which there is no active connection to a hypervisor. Without a > > connection, > > the data can't be accessed currently. I felt that this was a much > > simpler > > solution to the problem that building new APIs that do not require a > > connection > > to operate. > > We have a handful of places in our code where we call out to public > APIs to implement some piece of functionality. I've never been all > that happy about these scenarios. If we call the public API directly, > they cause havoc with error reporting because we end up dispatching > and resetting errors in the middle of an nested API call. Calling the > driver methods directly by doing conn->driver->invokeMethod() is > somewhat tedious & error prone because we're then skipping various > sanity tests that the public APIs do. With ACL checking now implemented > we also have the slightly odd situation that a public API check which > is documented as requiring permission 'xxxx' may also require permissions > 'yyyy' and 'zzzz' to deal with other public APIs we invoke secretly. > > I think there is a fairly strong argument that our internal > implementations > could be decoupled from the public APIs, so we can call methods internally > without having to go via the public APIs at all. > > On the flip side though, there's also a long term desire to separate > the different drivers into separate daemons, eg so the secrets driver > might move into a libvirt-secretsd daemon, which might explicitly > require use to go via the public APIs. Mulling this over last night, I think there may be an alternative implementation that would be sustainable long-term. You mentioned a desire to split the drivers into separate daemons eventually... It might seem silly today, but what if I went ahead and implemented a connection URI for each of the existing drivers? This would result in a 'network:///', 'secrets:///', 'storage:///', etc. Once complete, the existing code base could slowly be updated to utilize connections to those new URIs in preparation for splitting the code out into daemons. This would end up with the current libvirtd process eventually becoming a connection broker, with a compatibility shim to allow access to the API as it is currently defined for backwards compatibility.