[openstack-dev] [Nova] Things to tackle in Liberty

Neil Jerram Neil.Jerram at metaswitch.com
Fri Apr 10 15:48:58 UTC 2015

On 10/04/15 04:34, Kevin Benton wrote:
> IIRC there was some work to make the plugging call out to a script so
> all of the calls to various vswitches don't need to be in Nova. I would
> prefer this to removing all plugging logic from Nova.

Yes, indeed.  I had https://review.openstack.org/162468 (WIP: VIF plug 
script support for Nova) in my mind already, but 
https://review.openstack.org/#/q/owner:%22Brent+Eagles%22,n,z reveals 
lots more detailed work by Brent Eagles in this area.

> The main reason I would be hesitant to leave plugging completely out of
> Nova is that it requires an agent on the compute node, which isn't the
> case right now (e.g. plugins based on openflow, ovsdb, or something
> similar with a remote controller handling the setup of forwarding logic).

Understood, that it's nice to be able to do without an agent.

What I imagine, though, is that the _source_ of the plugging information 
could move from Nova to Neutron, so that future plugging-related code 
changes are a matter for Neutron rather than for Nova.  The plugging 
would still _happen_ from within Nova, as directed by that information.

(For libvirt, I believe the required information would be the interface 
type and parameters to go into the libvirt XML, and then any further 
processing to do after that XML has been launched.  I believe the latter 
is covered by the vif-plug-script spec, but not the former.)

However, on thinking this through, I see that this really is bound up 
with the wider question of nova-net / Neutron migration - because it 
obviously can't make sense for plugging information to come from Neutron 
if some people are not using Neutron at all for their networking.

Stepping right back, though, is it agreed in principle that detailed 
networking code should move from Nova to Neutron, if that is possible 
while preserving all existing behaviours?  If it is agreed, that's 
something that I'd like to help with.


More information about the OpenStack-dev mailing list