Open Stack

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:
https://etherpad.openstack.org/p/neutron-queens-ptg. You can also playback
the conversations here:


* Wednesday morning session: https://www.youtube.com/watch?v=58AyKXHkI-I

* Wednesday afternoon session: https://www.youtube.com/watch?v=LPxydx5ypAE

* Thursday morning session: https://www.youtube.com/watch?v=zSHIpkR9Jxg

* Thursday afternoon Neutron / Nova x-project session:
https://www.youtube.com/watch?v=kF5uat0MbuY

* Thursday late afternoon session: https://www.youtube.com/watch?
v=lJm8vIwxGec



Documentation

===========

* The documentation team has defined a new mission for itself:
https://review.openstack.org/#/c/499556/. 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
accordingly: https://review.openstack.org/#/c/503710/

* 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
team: https://wiki.openstack.org/wiki/CrossProjectLiaisons#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 (
https://github.com/openstack/neutron/tree/master/doc/source/admin/archives)
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



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 https://review.openstack.org/#/c/476652) to extract
specific objects methods from the different OVOs


DevStack

=====

* We have several patches that need the attention of DevStack core
reviewers: https://review.openstack.org/#/q/status:open+topi
c:new-neutron-devstack-in-gate

* Miguel Lavalle to talk to DevStack team to get them to pay attention to
these patches


Common Classification Framework

==========================

* The spec is: https://review.openstack.org/#/c/320439

* Making good progress towards releasing V1 during Queens

* Message sent to the distribution list requesting feedback on protocols
that should be supported: http://lists.openstack.org/pip
ermail/openstack-dev/2017-August/121531.html

* 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
changes.

* 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: https://review.openstack.org/396104

- RPC stuff and driver api: https://review.openstack.org/468265

- OVS firewall logging driver: https://review.openstack.org/468281

- CLI: https://review.openstack.org/#/c/409819/

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

- API and scenario test: https://review.openstack.org/#/c/482886/

- Functional test: https://review.openstack.org/#/c/418862/

- Documentation: https://review.openstack.org/#/c/480117/

* Trevor McCasland will conclude the implementation of QinQ network type
driver

* Boden Russell will re-propose network resource diagnostics for Queens:
https://review.openstack.org/#/c/308973/

* Implementation of “Provide Port Binding Information for Nova Live
Migration”   (http://specs.openstack.org/openstack/neutron-specs/specs/
pike/portbinding_information_for_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
client.

* 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
FWaaS

* 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


Testing

=====

* 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
patches:

- https://review.openstack.org/#/c/502222

- https://review.openstack.org/#/c/502224

* 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


API

===

* There is a TC defined community goal to move default policy definitions
from file-based maintenance to registering them in code (
https://governance.openstack.org/tc/goals/queens/policy-in-code.html)

- We already have a patch to implement this goal:
https://review.openstack.org/#/c/434997. Miguel Lavalle will follow it up

* Kevin Benton to look at Glance / Keystone for ENV variable lookup of
configuration files and will propose a patch


Reference implementation topics

========================

* OVS agent

- ovsdb_interface option will be deprecated in Queens, with the goal of
removing the CLI driver in Rocky: https://review.openstack.org/#/c/503070

- Removing of_interface option and ovs-ofctl related code in Queens:
https://review.openstack.org/#/c/503076

- 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 (https://github.com/openstack/os-vif)

- 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 ( https://bugs.launchpad.net/neutron/+bug/1707156)

- Rodolfo Alonso is working on a PoC: https://review.openstack.org/#
/q/status:open+branch:master+topic:osvif_migration

- 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 (https://github.com/openstack/neutron/blob/master/neutron/ag
ent/linux/interface.py#L410)

* 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: https://review.openstack.org/#/c/248177

- 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
work

* Linuxbridge

- To fix the Linuxbridge multinode job (https://bugs.launchpad.net/ne
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
stable


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
not
- 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: https://review.openstack.org/#/c/486450/. 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.
org/openstack/neutron-specs/specs/pike/portbinding_information_for_nova.html)
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 pre_live_migration stage of an instance
migration. The destination host binding will be set to active during the
post_live_migration stage. This will minimize the network down time during
the migration.

- Previous work to wire L3 during the pre_live_migration stage will be
updated accordingly: https://review.openstack.org/#/c/275073/,
https://review.openstack.org/#/c/275420/, https://review.openstack.org/#
/c/260738/

- 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 ( https://review.openstack.org/#/c/375580/)

- 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: https://specs.openstack.org/openstack/neutron-specs/specs/ba
cklog/pike/strict-minimum-bandwidth-support.html. Rodolfo Alonso, Slawek
Kaplonski and Miguel Lavalle have committed to continue implementation in
Queens

- 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
point
https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#core-review-hierarchy

* 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170924/365db578/attachment.html>