settingsLogin | Registersettings

[openstack-dev] [nova][neutron] Queens PTG recap - nova/neutron

0 votes

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


  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.





OpenStack Development Mailing List (not for usage questions)
asked Sep 18, 2017 in openstack-dev by mriedemos_at_gmail.c (15,720 points)   2 5 10