It is again that time of the year when there was OpenStack PTG, and again, it was virtual. Neutron team had 4 sessions during the week of the PTG. Below is the summary of what we discussed during that time. Etherpad with agenda and all notes from the sessions is available at OpenDev Etherpad
Day 1 (Monday)
Retrospective of the Wallaby cycle
- we accomplished our community goals this cycle, like e.g. rootwrap to privsep migration,
- 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 Launchpad 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 the Neutron,
- 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. 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 Shanghai PTG 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 Launchpad. 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 operators about:
- 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 next PTG.
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 and the spec
- [RFE] Allow explicit management of default routes and the spec
- Allow multiple external gateways on a router and the spec
- [RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers & bgp-peering from such routers over internal & external Neutron Networks and the spec
- [RFE] BFD for BGP Dynamic Routing and the spec. 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 project. Few cycle back we were thinking about including it in the Neutron stadium but finally that never really happend. But now both Ericsson and Red Hat are interested in that project so we may want to reconsider that again. During the Xena cycle we will keep it as an unofficial project, but we will also keep an eye on it to see how things will go. We will also investigate if it could maybe be included in the Neutron main repository as a service plugin. That can be easier to do than yet another stadium project to maintain.
OVN support for BGP routing
Our next topic on Tuesday was again about BGP, but this time Dan Sneddon from Red Hat shown us idea about new agent to support BGP with ML2/OVN backend. Currently there is no any RFE about that proposed officially for Neutron. This is just an experimental project, completly outside of the official Openstack and Neutron gouvernance. We agreed that next step which Dan and his team will do upstream will be proposal of the RFE and official spec for Neutron to describe this proposal. They will also discuss details of their approach with the Ericsson team which is also doing similar BGP enhancements but for ML2/OVS backend (see above) to hopefully reuse as much as possible between those solutions and to not duplicate code.
Review of the existing blueprints
As last topic during second day of the PTG we went through the list of the old, still opened blueprints. We finally decided to close many of them so our backlog is now a bit shorter. List of still opened blueprints can be found at Launchpad.
Day 3 (Thursday)
OVN as default backend in the Devstack - AMA session for other teams
As first topic on Thursday we had Ask Me Anything session for other teams about switch of the default Neutron backend in Devstack from ML2/OVS to ML2/OVN. Lucas made recap of all what was actually done regarding this topic already and what we are still waiting for. We also explained to the people from other teams how such change may (but shouldn’t really) impact e.g. their development workflow or CI jobs. We will probably need to work with some teams, like e.g. Kuryr to fix their jobs after switch will be done or to explicitly switch such broken jobs back to the ML2/OVS backend. The other project which will require explicit switch to ML2/OVS backend is networking-sfc which is intended to work only with the ML2/OVS for now. We also agreed that we want to switch it in the Devstack in next 2 weeks. Final patch to do that is proposed already in Gerrit.
Status of the migration to the “nftables”
Rodolfo gave as great recap about current status of the iptables, nftables and legacy APIs in nftables. Currently Neutron works fine with nftables and it’s legacy iptables APIs so we should be good even for new distributions which may completly drop old iptables solution.
Secure RBAC policies
As next topic on the third day we were reviewing together all of our new default API policies which can be found at ethercalc. We had some doubts in few cases but we agreed on how it should be finally. Patches for that are already proposed, and even merged in some cases. This session was recorded and recording is available here.
Secure RBAC policies - common session with Nova and Keystone teams
It was mostly Nova-Keystone cross project session but there were also topics related to the Neutron so we joined it. We discussed there how to handle system scope tokens, which don’t have project_id in the Neutron as almost all resources in Neutron belongs to some project. More detailed summary of that discussion can be found in the policy popup etherpad.
Day 4 (Friday)
Cross project session with Interop WG
As a first thing on Friday we had session with Interop working group. Martin Kopec from that group gave as quick recap of what this group is doing and what they would like from our team. We then looked at our new APIs in Neutron and we agreed that “address_groups” is good candidate to be tracked by Interop group as Neutron capability. Based on the guidelines which Martin gave us we will also review our other APIs to see if something else could be added there as well.
Secure RBAC recap
This was session done by Lance from Keystone team where he gave us recap of all what was discussed with various teams regarding secure RBAC policies. Details of all those discussions can be found in the policy popup etherpad.
Cross project session with Nova
On the session with Nova we discussed 2 topics:
- support guaranteed minimum packet rate QoS policy,
- live-migration with MTU change
Details of that discussions and agreement on each of the topics can be found in the Nova’s etherpad.
As last thing on Friday we took team photo (screenshot) which You can see below.
I want to thank all of You who particpated in the discussions during the Neutron’s PTG sessions. It was great and very productive week. We discussed many topics there and I think we have some plan about what we will work on during the Xena cycle. Take care of Yourself and see You online :)