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