Need to provide a formal API for Nova to use to plug/unplug VIFs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Invalid
|
High
|
Gary Kotton |
Bug Description
The current interaction model between Nova and Quantum is critically flawed in a number of respects
- There is a hard configuration dependency between Quantum & Nova. ie When changing the Quantum network driver implementation, the admin must also update the Nova libvirt_vif_driver config parameter to match.
- Some quantum drivers are providing custom plugin impls for the Nova libvirt VIF driver classes. This exposes Quantum to the internal implementation details of the libvirt driver in Nova. These impl details ought to be private to Nova since they can be changed arbitrarily at any time which will break Quantum plugins (eg see bug 1046758).
- Some Quantum drivers are tied to usage with Nova and libvirt. This is more or less the same point as above - since the drivers need to provide custom libvirt VIF drivers to work with Nova, this is tieing Quantum into Nova + libvirt, preventing its re-use with other non-libvirt drivers or applications like oVirt.
- Some Quantum drivers are doing work which belongs under the hypervisors' control. eg the Quantum Linux bridge driver is wanting to create TAP devices itself & add them to the bridge. This is only achievable by using the libvirt type=ethernet VIF config. Not only is this config designated unsupported by RHEL (due to its inherent security limitations), but this can only ever work with KVM. libvirt's LXC and Xen drivers do not use TAP devices for their networking, and want to be in charge of adding their own interface to the bridge.
All these problems could be solved if Quantum exposed a formal API for compute services to call to plug/unplug VIFs, instead of relying on hooking into the libvirt VIF driver internal impls. The API would do any port configuration work that might be neccessary, and then return information about where the VIF should be attached & what parameters it should use. The compute service would then take care of actually deciding the optimal libvirt configuration & let the hypervisor actually create & attach the VIF to the network.
Changed in quantum: | |
assignee: | nobody → Gary Kotton (garyk) |
milestone: | none → grizzly-1 |
Changed in quantum: | |
milestone: | grizzly-2 → none |
The one point I strongly agree with is that vif-drivers should not exist in Quantum, as it makes it impossible to have unit tests that confirm they are not broken. The fact that a vif-driver still exists in the Cisco plugin is an oversight as this is not a configuration used by many in the community.
I also agree that there's room for improvement in terms of removing the hard configuration dependency. The existing vif-plugging design is from Diablo, when Quantum was rarely used and so we were trying to be minimally invasive. At this point, it would be nice if when Nova creates a port, Quantum can tell Nova which vif plugging to use, and any additional parameters.
I think its worth having a discussion on this at the Grizzly summit. I'll add it to my list.