[neutron] April 2021 - PTG Summary
skaplons at redhat.com
Mon Apr 26 14:44:51 UTC 2021
Below is my summary of the Neutron sessions during the PTG last week.
Etherpad with agenda and all notes from the sessions is available at https://
If You want to discuss some topic in more details, please start new thread for it to
keep this one clean.
## Day 1 (Monday)
### Retrospective of the Wallaby cycle
* we accomplished our community goals this cycle, like e.g. rootwrap to
* migration to the secure RBAC,
* many performance improvements,
* CI improvements and the job simplification/reducing,
* stable team, and a lot of small patches from all around the world,
* OVN feature gap with OVS is shrinking,
* team support to implement address groups, including RBAC support.
In the list of not so good things we mentioned:
* During the previous PTG we were talking about some OVN related
guides/sessions but we didn't made any,
* networking-midonet - (yet another) stadium project deprecated due to lack of
maintainers, but it's better to have them clearly marked as out of stadium,
than false expectations - we can bring such projects back when needed anyway,
* still unstable CI, mainly tempest and tempest-plugin jobs, also during this
release functional tests.
As for action items for the _Xena_ cycle, we listed couple of things:
* Miguel wants to do the ovn knowledge share internally in his company and
later share the material,
* we will keep working on the improvements for our CI, list of all opened, CI
related bugs can be found at
https://tinyurl.com/neutron-gate-failures and we will work on
reducing that list in next months.
* Rodolfo and Miguel will follow up on Nova's plans to drop eventlet and move to
the threading and will investigate if we can try to do something similar in
* Akihiro raised good point about ML2/OVN and stadium projects. We should
clarify the support plan for OVN in all of our stadium projects. Lajos and
Lucas volunteered to work on that.
### Secure RBAC - testing - discussion with QA team
As next session in the first day, we attended QA team's session about testing
new secure RBAC policies. Summary of that discussion can be found in the
etherpad: https://etherpad.opendev.org/p/qa-xena-ptg. QA team wants to switch
each project to enforce new defaults and the system scope tokens in the
Devstack. We will have to monitor that and check what needs to be fixed on our
side to accomplish that.
### Deprecated hybrid plug and the iptables_hybrid firewall driver
Bence proposed discussion about potential deprecation of the iptables_hybrid
firewall driver as we have now native openvswitch driver too. After discussion
we decided that we are not going to deprecate it, at least for now. There are
known differences between those two drivers and there is still many usecases
where people wants to use iptables_hybrid driver.
### Future of the Linuxbridge backend
As the last topic of the first day we discussed future of the Linuxbridge
backend and ML2 driver. The same topic was discussed in the http://kaplonski.pl/
blog/shanghai_ptg_summary/ and then, based on the
feedback from operators we decided that we are not going to deprecate this
backend anytime soon as many people are still using it.
But now we are couple of cycle later and things didn't change a lot. We still
don't have anyone who would like to maintain it. In most cases it works fine but
there are also pretty many bugs reported for that backend, which don't have
owners - see https://tinyurl.com/linuxbridge-bugs. But things may
change in the future and e.g. removal of the legacy iptables from the main
distributions may makes things harder to work.
We again had feedback, e.g. from Jon that NASA is using that driver and want's
to keep using it. But from the other hand in the core Neutron we don't have
anyone interested in maintaining it currently.
The outcome of the discussion is that we will again raise that topic and ask
- who is using it and what are the use cases addressed by that driver - maybe we
can help with proposing another solution,
- who is willing to help with maintenance of that backend.
If You are using Linuxbridge backend, please give us such feedback.
For Xena status is that we still do our best to keep Linuxbridge backend to be
running and fully supported but we will also revisit its status again in the
## Day 2 (Tuesday)
### Continuation of "L3 feature improvements"
During the second day of the PTG we had very interesting discussions about L3
improvements. We discussed bunch of the RFEs proposed by Bence, Lajos and Manu:
* [RFE] Add BFD support for Neutron https://bugs.launchpad.net/neutron/+bug/
and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/767337
* [RFE] Allow explicit management of default routes: https://bugs.launchpad.net/
and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/781475
* Allow multiple external gateways on a router: https://bugs.launchpad.net/neutron/
and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/779511
* [RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers &
bgp-peering from such routers over internal & external Neutron Networks https://
and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/783791
* [RFE] BFD for BGP Dynamic Routing: https://bugs.launchpad.net/neutron/+bug/
and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/785349.
That one still needs to be discussed and approved during the drivers meeting.
General outcome from the discussion is that during the Xena cycle we at least
wants to have all those specs merged to have agreement about implementation
details. When that will be done, Bence, Lajos and others from Ericsson will work
on the implementation of those RFEs.
### Tap-as-a-service (taas) project
Next topic which we discussed during Tuesday's session was about
Tap-as-a-service: https://opendev.org/x/tap-as-a-service project. Few cycle
back we were thinking about including it in the Neutron stadium but finally that
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: This is a digitally signed message part.
More information about the openstack-discuss