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: 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. In effect, today nothing would change, other than the storage driver would use 'secrets:///' to open a connection for its backends. Eventually, though, all drivers would use the new URIs (the actual APIs implemented would not need to change), allowing an easier split of the daemons. The compatibility shim I mentioned would just be some code to open a connection to the proper URI, make the request, close the connection, and return the data. The one thing that would be needed at some point (which I'm not sure how to really implement today), would be a restriction on which API functions could be called. Basically, if you opened a connection to 'secrets:///', you should only be able to access secrets. If you tried to access network information, an error would need to be thrown in order to prevent all of the drivers having a connection to all of the other drivers, burning up sockets on the host system. I'm guessing that this could be implemented using the ACL framework that is already in place, but I haven't dug through the code to verify this yet. In this long-term desire to split libvirt into multiple daemons, is there a plan to also create a libvirt-domaind? Currently, the various hypervisors don't actually know how to read the domain XML fully, so a daemon like that would probably be desired. As a bonus, it could also allow a single connection to view all running domains, regardless of which hypervisor driver actually created it, though that isn't strictly needed. The reason I ask is that currently, it is nigh impossible to determine driver inter-dependencies automatically. If strict controls were in place to prevent cross-URI calls (in effect making libvirt as a single process act as though it were already split), it should become easier to determine a driver's dependencies at compile (or possibly even run) time. Having that data would allow for a true dependency-based driver load order. While I think implementation of a dependency-aware driver loader is probably beyond my personal programming skills, it would be the best method in the long run. Though, in a multi-process model, it may be simpler to define a new connection function that waits (optionally until a timeout expires) for the connection to succeed, performing automatic retries in that time. This would allow the various daemons to start in any order, yet automatically initialize in the proper dependency order. Any circular dependency would, of course, cause a long hang during startup, but a timeout could detect that and fail the startup of libvirt as a whole. The same timeout-based connection function could also be used in the single-process model, of course, removing the need for driver load order to be changed at all if all existing code used the proposed new URIs. In effect, the driver load order change would be needed today, but once all existing code is updated, the change could be reverted to the current free-for-all model, as there would be implied control over that by virtue of the fact that the drivers would wait for their dependencies to finish connecting.