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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
