settingsLogin | Registersettings

[openstack-dev] [neutron] Denver PTG summary

0 votes

Hi All!

Following below is a high-level update of what was discussed during the
PTG. If there is something I left out, please reply to this email thread to
add it. However, if you want to continue the discussion on any of the
individual points summarized below, please start a new thread so we don’t
have a ton of discussions going on attached to this update.

You can find the etherpad we used during the PTG here: You can also playback
the conversations here:



  • The documentation team has defined a new mission for itself: This means that the Neutron team
    has to create and maintain its own documentation. The documentation team
    will only provide tools and guidance.

  • Code patchsets must include documentation from now on, when applicable.
    This will be enforced by all code reviewers. As a consequence, we will not
    use the DocImpact tag anymore. We are updating the contributors guide

  • Patches that impact the API must depend on a corresponding patch in
    neutron-lib that update api-ref

  • Boden has graciously accepted to be the liaison with the documentation

  • The release checklist has to be updated to include a step to insure there
    are no broken links in the docs

  • We need volunteers to move the archived configuration guide (
    into the networking guide

  • Pike install guides need to be verified. We also need volunteers for this

  • The stable/pike document backport policy is to backport patches as they
    come, with the exception of API reference contributions, which must target
    the master branch of neutron-lib



  • New callback payload adoption: we will treat the adoption of the new
    payload style objects as we have been with other lib impact changes.

  • Decoupling of DB related access for neutron-lib: recommendation was to
    move OVO fields definitions to neutron-lib, instead of the currently
    proposed approach (PoC to extract
    specific objects methods from the different OVOs



Common Classification Framework


  • The spec is:

  • Making good progress towards releasing V1 during Queens

  • Message sent to the distribution list requesting feedback on protocols
    that should be supported:

  • FWaaS, SFC and Dragonflow have shown interest in adopting CCF

  • Adding classifying based on neutron resources is being considered. A SFC
    PoC is going to be implemented

CLI related topics


  • With OSC resource attributes extensions must be added directly/statically to
    the sdk's resource and then consumed in the client, unlike the
    python-neutronclient, where that doesn’t require any client-side code

  • As a consequence, we will not drop support for python-neutronclient until
    we achieve parity.

  • Boden Russel will follow up with a message to the mailing list to request
    the current status of support for attribute extensions in OSC

  • Akihiro Motoki will discuss the future of LBaaS CLI with octavia team

  • yushiro will discuss with the FWaaS team the future of the v1 CLI/API

Pike backlog plans


  • Security group logging. Remaining 4 functionality patches are ready for
    review and targeted to merge by Q-1:

  • Logging agent extension:

  • RPC stuff and driver api:

  • OVS firewall logging driver:

  • CLI:

  • Security group logging: testing and documentation patches are targeted to
    merge in Q-2

  • API and scenario test:

  • Functional test:

  • Documentation:

  • Trevor McCasland will conclude the implementation of QinQ network type

  • Boden Russell will re-propose network resource diagnostics for Queens:

  • Implementation of “Provide Port Binding Information for Nova Live
    Migration” (
    pike/portbindinginformationfor_nova.html) will be continued by Miguel
    Lavalle (see also the Nova / Neutron section below)

  • Kevin Benton will follow up with Ann Taraday to find out the current
    status of the DB engine façade adoption

  • Akihiro Motoki to create an etherpad or similar document to track the
    status of api reference documents in neutron-lib

  • Slawek Kaplonski to propose a patch to implement the Quota details

  • FWaaS update:

  • Priority during Queens is to finish and stabilize V2 API and provide
    support to L2. Support from L3 - L7 will be implemented in future releases

  • The second priority during Queens is the implementation of API and
    scenario tests, with the aim of encouraging distros to ship and support

  • Enhancing security groups with a 'deny' attribute

  • Pros: unlocking relatively quickly the implementation of some use cases

  • Cons: implementing competing ways to achieve the same functionality in
    security groups and FWaaS V2

  • After considering pros and cons, consensus was reached to focus in Queens
    on stabilizing FWaaS V2



  • The CI and L3 sub-teams will cooperate on making the DVR-HA multinode job
    voting to achieve overarching coverage

  • The L3 sub-team will add a regular CI topic to their weekly meeting
    agenda, to make sure progress is achieved on this subject

  • We will split the Tempest plugin in Neutron into a different branch-less
    repo, according to the community goal. This is achieved in the following



  • In trunk fullstack testing, we run multiple ovs-agents in a single node.
    As a consequence, when a port is removed from a trunk bridge all the agents
    will attempt to clean resources from the given trunk bridge

  • Armando Migliaccio will propose a temporary fix to associate an agent
    prefix to the trunk bridge

  • In parallel, Jakub Libosvar will continue working on a more permanent
    solution based on OVS sandboxing



Reference implementation topics


  • OVS agent

  • ovsdb_interface option will be deprecated in Queens, with the goal of
    removing the CLI driver in Rocky:

  • Removing of_interface option and ovs-ofctl related code in Queens:

  • We need a mechanism to migrate to OVS Firewall. Kevin Benton agreed to
    file a bug to add logic to the L2 agent to drop iptables on filtering
    bridges when an operator switches to OVS Firewall

  • Adoption of os-vif in Neutron (

  • The goal is to replace the agent Linux interface module with calls to
    os-vif so VIF plugging and un-plugging logic doesn't have to be duplicated
    in Neutron (

  • Rodolfo Alonso is working on a PoC:

  • Related to this is the the existence of code to create interface in a IVS
    (Indigo Virtual Switch) bridge. Kevin Benton indicated that this code can
    be removed (

  • David Shaughnessy is working on a PoC of a DVR OpenFlow implementation

  • We agreed to continue this PoC under the assumption that we will
    stabilize the current DVR before attempting to merge any of the new code

  • The proposed code in the PoC provides its own classes for the new type of
    router, so it is well isolated from the current in tree code. We intend to
    keep it this way

  • We will focus on fullstack testing for this new feature, so we don't
    complicate the current suite of DVR tests with more Tempest jobs.

  • Kevin Benton will not have time to work on replacing l2_pop with
    information in the data model

  • We have a patch that never merged to setup arp_responder in the
    integration bridge:

  • The challenge is to figure out how to store the relevant information in
    the data model and to come up with a safe migration plan

  • Kevin agreed to help review the code if we get someone to continue this

  • Linuxbridge

  • To fix the Linuxbridge multinode job (
    utron/+bug/1683256), Kevin Benton will follow up with infra to set up
    tunnels across the compute nodes so that multicast in the underlay does not
    have to be assumed (devstack gate)

  • Trunk scenario needs to be fixed to make the Linuxbridge scenario job

L3 flavors

* The assignment of a service provider to a router is implemented as a
callback subscribed to router create pre-commit event.
- This mechanism can be racy.
- Isaku Yamahata and Manjeet Singh Bhatia have volunteered to work on
fixing the events systems, with Armando Migliaccio and Takashi Yamamoto
reviewing the code.
* Midonet supports IPv6 floating IPs but the reference implementation does
- If we lift the constraint in l3_db then users can create floating IPs
with v6 addrs but they will never be able to associate them unless midonet
or another l3 backend that supports them is used
- A decision was left pending on whether to support IPv6 floating IPs
* Currently we don't have a way to manage the compatibility or lack thereof
between L3 flavors and ML2 drivers
- Armando Migliaccio will propose an approach to handle this

Floating IPs for routed networks


  • A spec is up for review: It
    incorporates the feedback of one large operator (GoDaddy). Other operators
    are encouraged to review and provide feedback

  • The team decided to split this spec in two. The first one will focus on
    adding a 'service_type' attribute to floating IPs, which may be useful for
    other use cases.The second one will focus on the changes needed to BGP
    Dynamic Routing to implement floating IPs for routed networks

  • This is targeted for Queens

Nova / Neutron integration


  • Neutron port binding extension for live migration

  • This extension (spec:https://specs.openstack.
    will provide an API to create bindings in multiple hosts for a port. Only
    one of those bindings can be active at a time

  • When this extension is available, Nova will use it to bind ports in the
    destination host during the prelivemigration stage of an instance
    migration. The destination host binding will be set to active during the
    postlivemigration stage. This will minimize the network down time during
    the migration.

  • Previous work to wire L3 during the prelivemigration stage will be
    updated accordingly:,,

  • This work will proceed in parallel with the implementation of os-vif
    object negotiation and could be merged at the end of the cycle

  • This work will also proceed in parallel with the move in Nova of the port
    orchestration to the conductor (

  • Sean Mooney and Rodolfo Alonso will work on the Nova side. Miguel Lavalle
    will work on the Neutron side

  • Using os-vif for port binding negotiation. Sean Mooney and Rodolfo Alonso
    already have PoC code. They will continue the work during Queens

  • Bandwidth-based scheduling

  • Some work on the Neutron side has already started along the lines of the
    following spec:
    cklog/pike/strict-minimum-bandwidth-support.html. Rodolfo Alonso, Slawek
    Kaplonski and Miguel Lavalle have committed to continue implementation in

  • This feature has a strong dependency on the implementation of nested
    resource providers in the Placement service, which is expected to complete
    in Q-1

Neutron to Neutron connectivity with BGPVPN


  • Thomas Morin proposed to use BGPVPN to define a router in an OpenStack
    that has an 'alias router' in a remote OpenStack (this has to be done
    symmetrically in both OpenStacks). VPN identifiers are exchanged to
    establish the connection and orchestration is not required.

  • Federation is not necessary. All that is required is for each OpenStack
    to have an admin user from the other side configured in order to ascertain
    the existence of the alias

  • It was agreed that the next step will be to write a specification

Community related topics


  • The team brainstormed on steps to take to develop new core reviewers. The
    following actions were agreed upon:

  • Establish a mentoring process, whereby people interested in progressing
    to core will be paired with current team members. This will require
    identifying those people interested on being mentored as well as people
    interested in mentoring

  • Establish deep dive sessions to train people on deep technical aspects of
    the different components of Neutron

  • We are going to clean-up on-boarding documentation

  • We are going to respin and maintain low-hanging-fruit list to address
    concerns over fruits being not very low hanging

  • We will identify areas where contributors are needed, using as a starting

  • Bug management issues. Over the past few months, we have had difficulty
    getting weekly volunteers to triage bugs

  • We decided to define a fixed rotation among the team members. Miguel
    Lavalle will make a proposal

  • We will follow up on implementing an IRC bot to notify in the Neutron
    channel the filing of new bugs

    OpenStack Development Mailing List (not for usage questions)
asked Sep 25, 2017 in openstack-dev by Miguel_Lavalle (2,460 points)   1 4