Open Stack

The Nova and Neutron teams had two cross-project sessions in Barcelona 
at the Ocata summit, the full etherpad is here:

https://etherpad.openstack.org/p/ocata-nova-neutron-session

----

The entire first session was spent discussing a proposal to change how 
Nova and Neutron handle port binding during live migration:

https://review.openstack.org/#/c/309416/

At a high level, this would have Nova create a 2nd inactive port binding 
for the target host during pre-live migration. If that failed, Nova 
would exit the live migration operation early. We also agreed that 
Neutron would provide real live errors on a port binding failure, not 
the dreaded 'binding_failed' vif type.

There will be a new generic port bindings REST API that comes with a new 
Neutron extension. Nova will check for the extension and if available 
use the new flow to create the 2nd inactive target host binding in 
pre-live migration, then make that target host binding active in 
post-live migration and then remove the first source host port binding 
in post-live migration.

There are still open questions in the etherpad about what the REST API 
will look like and how the actions will be performed, including if we 
can have more than one active port binding. For the sake of simplicity 
during the session, we asserted that right now there is only one active 
port binding, but that might change. The details will be hashed out in 
the Neutron spec.

----

The Thursday session started with discussing next steps for os-vif work. 
Nova has two main goals which can be done in parallel:

1. Convert remaining legacy vif types to os-vif objects. ovs and 
linuxbridge were done in the Newton release. There is a patch up for 
converting vhostuser already. Daniel Berrange (danpb) plans on working 
on the rest if there are no other volunteers. He also plans on creating 
the git repos and create the initial basic plugins, and then expect the 
Neutron vendor plugin maintainers to take over ownership. Please 
coordinate with Daniel Berrange if you are already working on some of 
this so we don't duplicate the effort.

2. Start working on the vif type negotiation between Nova and Neutron 
during port binding. This is where Nova determines the list of supported 
vif types (and os-vif object/plugin versions) on the compute host and 
sends that to Neutron. Neutron then picks the one to use from the list 
and returns that to Nova in the vif binding details, or fails if it 
can't use any of them. Nova will have to do some filtering of the list 
based on instance/host/flavor information, e.g. vhostuser plugin might 
be installed but might not actually work if the host is not configured 
properly. Ian Wells volunteered to start working on this with direction 
from Daniel Berrange.

----

There was a question about testing the Nova metadata API service in the 
Neutron jobs in the gate, specifically for grenade multinode + neutron. 
During the session I waved my hands that I thought we turned on the 
metadata service in all jobs and disabled config drive by default during 
Newton when we removed the postgresql job, but needed to confirm. 
Consider it confirmed:

The devstack change to not force config drive by default:

https://review.openstack.org/#/c/357446/

And devstack-gate:

https://review.openstack.org/#/c/357443/

There are already tests in Tempest which use config drive when creating 
the instance, so we have coverage both ways.

----

we talked a little bit about nova-network deprecation and next steps 
there. The main issue right now is all of the CI jobs that are still 
using nova-network, including third party CI jobs running against Nova. 
I need to start getting together with the third party CI maintainers for 
Nova and see what their timeline is for moving to using Neutron.

The other big problem is the cells v1 CI job relies on nova-network 
because cells v1 doesn't support the nova/neutron vif plugging 
timeout/event callback routine which was needed to stabilize the CI 
system when using neutron. Chronologically speaking, nova can't remove 
cells v1 support until we have cells v2 multi-cell support (which is a 
nova goal for Ocata). And nova can't remove nova-network until we can 
remove cells v1 support. So the idea in the room was to further disable 
nova-network in Ocata by only allowing it to run in a cells v1 
configuration. So basically on startup the nova-net service checks if 
cells v1 is enabled and if not, the service dies. I believe Dan Smith 
said he was going to work on adding that check in the Nova code.

----

Ian Wells brought up two issues that were of importance to Gluon, but 
they were also somewhat generic.

1. Ian has a spec:

https://review.openstack.org/#/c/390513/

Which proposes a new Neutron extension to put routing information 
directly in the port details so that Nova can bypassing looking up 
related resources (like subnets) to get this information for a given 
port. Basically, short-circuit the amount of work that Nova has to 
perform just to get routing information for a port. This would be 
considered a general improvement to the Nova flow performance-wise, we 
just need to review the spec as we didn't get into details in the session.

2. Ian raised some concerns about bugs in the deferred IP allocation use 
cases added by Carl Baldwin in Newton. However, in talking through the 
scenario it sounded like we might not actually have a problem and Ian 
was going to go back and do some testing on the latest Newton code.

-- 

Thanks,

Matt Riedemann