There were a few nova/neutron interactions at the PTG, one on Tuesday
 and one on Thursday .
Neutron port binding extension for live migration: This was discussed
at the Ocata summit in Barcelona  and resulted in a Neutron spec 
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  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 . Sean Mooney said
he could work on the Nova changes for this. The nova spec , started
by John Garbutt in Ocata, would need to get updated for Queens. Miguel
Lavalle will drive the changes in Neutron.
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.
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.
There were several other use cases discussed in both  and  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.
OpenStack Development Mailing List (not for usage questions)