[Openstack-operators] [nova][neutron] Queens PTG recap - nova/neutron

Matt Riedemann mriedemos at gmail.com
Mon Sep 18 18:49:30 UTC 2017


There were a few nova/neutron interactions at the PTG, one on Tuesday 
[1] and one on Thursday [2].

Priorities
----------

1. Neutron port binding extension for live migration: This was discussed 
at the Ocata summit in Barcelona [3] and resulted in a Neutron spec [4] 
and API definition in Pike. The point of this is to shorten the amount 
of network downtime when switching ports between the source and 
destination hosts during a live migration. Neutron would provide a new 
port binding API extension and if available, Nova would use that to bind 
ports on both the source and destination hosts during live migration and 
switch which one is active during post-migration. We discussed if this 
should be dependent on os-vif object negotiation and agreed both efforts 
could be worked concurrently and then we'll see if we should merge them 
at the end, mostly to avoid having to redo a bunch of work if vif 
negotiation comes later. We also discussed if we should make the port 
binding changes on the Nova side depend on moving port orchestration to 
conductor [5] and again agreed to work those separately and see how the 
port binding code looks if it's just started in the nova-compute 
service, mainly since we don't have an owner for [5]. Sean Mooney said 
he could work on the Nova changes for this. The nova spec [6], started 
by John Garbutt in Ocata, would need to get updated for Queens. Miguel 
Lavalle will drive the changes in Neutron.

2. Using os-vif for port binding negotiation: Sean Mooney and Rodolfo 
Alonso already have some proof of concept code for this. We will want to 
get the gate-tempest-dsvm-nova-os-vif-ubuntu-xenial-nv job to be voting 
with any of this code. We also said we could work this concurrently with 
the port binding for live migration work above.

3. Bandwidth-based scheduling: this has a spec already and some work was 
done in Neutron in Pike. There are multiple interested parties in this 
feature. This will depend on getting nested resource providers done in 
Nova, really within the first milestone. Rodolfo owns this as well.

Other discussion
----------------

There were several other use cases discussed in both [1] and [2] but for 
the most part they have dependencies on other work, or they don't have 
specs/designs/PoC code, or they don't have owners. So we on the Nova 
side aren't going to be focusing on those other items.

[1] https://etherpad.openstack.org/p/placement-nova-neutron-queens-ptg
[2] https://etherpad.openstack.org/p/nova-ptg-queens
[3] https://etherpad.openstack.org/p/ocata-nova-neutron-session
[4] 
https://specs.openstack.org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html
[5] 
https://blueprints.launchpad.net/nova/+spec/prep-for-network-aware-scheduling-pike
[6] https://review.openstack.org/#/c/375580/

-- 

Thanks,

Matt



More information about the OpenStack-operators mailing list