Comment 10 for bug 1046766

Yep, IMHO the existence of these various non-config related setup tasks in the VIF drivers is one of the critical problems with the current design. The VIF driver impl is specific to libvirt, but those non-config setup tasks need to be done by any Nova virt driver that wishes to integrate with Quantum. The tasks also need to be done if any non-Nova projects (like oVirt) want to use Quantum for network management. In essence these VIF driver setup tasks are Quantum code that has been punted to Nova, which introduces a mutual dependency between Quantum & Nova. The only way to avoid duplication of code for these setup tasks is to get a strict separation of setup vs configuration information, and then have all the setup tasks be in Quantum code.

My 33,000ft view is that Quantum would need some kind of "plug" and "unplug" APIs that Nova virt drivers (or non-Nova virt code) can invoke. The "plug" API would be given information about what network the VIF is intended to plug into. They would do whatever VIF setup tasks are required, and then return a short config document specifying how the hypervisor should connect the VIF to the network. The virt driver would solely be responsible for translating this config into whatever the hypervisor config needs to look like.

Now I understand that as it stands the Quantum API is somewhat detached from the compute nodes where work may be done by optional agents. So adding this kind of "plug" and "unplug" APIs into the current Quantum API service may not work with its architecture. Thus it might be necessary to have a local-only API exposed by the agent running on the compute node to hold just the "plug" and "unplug" operation implementations. For Quantum drivers which don't already have an agent, this would necessitate having a simple api-only agent on the node, but I think this is worthwhile to get good architectural separation between Quantum and Nova.