On Fri, Jan 26, 2018 at 13:35:27 +0000, Daniel Berrange wrote:
Currently the secondary drivers can only be used if you have a connection to a primary hypervisor driver. This series introduces explicit URIs that allow opening a connection that only talks to a specific secondary driver. In the future these URIs will resolve to individual daemons containing those drivers.
I'm so glad to see this, it felt awkward to hand off the connection pointer through massive call chains. The only thing I'm afraid of in the future is that once the daemons are split, if the user has a valid connection pointer, the code may still fail if it fails to open a secondary connection to e.g. the storage driver. All this while the original caller already had a valid pointer.
This also allows us to fix long standing problems with most code that uses secrets internally. We need to pass a virConnectPtr into such code but some call stacks don't have a connection available. In some cases we open a temporary connection to the QEMU driver, but this is suboptimal for deployments without the QEMU driver present.
That always grossed me out.
Daniel P. Berrangé (10): storage: move driver registration back to end of the file storage: allow opening with storage:///system and storage:///session URIs network: move driver registration back to end of the file network: allow opening with network:///system and network:///session URIs nwfilter: allow opening with nwfilter:///system URI interface: allow opening with interface:///system and interface:///session URIs nodedev: allow opening with nodedev:///system and nodedev:///session URIs secret: allow opening with secret:///system and secret:///session URIs
All of the patches above copy-paste code which has wrong coding style, so all need to be fixed.
storage: open secret driver connection at time of use storage: remove virConnectPtr from all backend functions
And the opening of the helper connection really needs a helper function. ACK with the cosmetic tweaks