Re: [libvirt] [RFC PATCH 0/7] Adding 'config' driver
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.
This driver is technically what one may call a hypervisor driver, but
it
does not implement any domain operations. It simply exists to handle requests
by drivers for access to informatino that would otherwise require a connection.
The URI used for this driver is 'config:///' and has been tested working on 4
different machines of mine, running three different distributions of Linux
(Archlinux, Gentoo, and CentOS). Being a very simple driver, I would expect
it to work pretty much anywhere.
I would love to hear any comments and suggestions you may have about this
driver. At the very least this plus my next patchset resolves the startup
race condition on my machine. If a more robust setup (likely a new internal
API) is in the works, this driver could act as a band-aid to allow access
to this type of data in the interim if a better resolution is a ways off.
One big concern I have about this approach is the fact that once we add
this 'config:///' driver, it is very hard for us to ever remove it again,
since this concept leaks out into the public API. So we're going to want
to be very sure that this is something we wish to support long term, and
I don't really have such confidence myself.
I'd like to understand a bit more about the dependancy issue you're facing
to see if there's something else we can do to address it.
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 :|