
<html>

<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

</head>

<body><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Hi,</p>

<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><span style="font-family:monospace;">Below is my summary of the Neutron sessions during the PTG last week.<br />Etherpad with agenda and all notes from the sessions is available at https://etherpad.opendev.org/p/neutron-xena-ptg </p>

<p> </span></p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">If You want to discuss some topic in more details, please start new thread for it to keep this one clean.</p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br />## Day 1 (Monday) <br /><br />### Retrospective of the Wallaby cycle <br />Good things: <br />* we accomplished our community goals this cycle, like e.g. rootwrap to <br /> privsep migration, <br />* migration to the secure RBAC, <br />* many performance improvements, <br />* CI improvements and the job simplification/reducing, <br />* stable team, and a lot of small patches from all around the world, <br />* OVN feature gap with OVS is shrinking, <br />* team support to implement address groups, including RBAC support. <br /><br />In the list of not so good things we mentioned: <br />* During the previous PTG we were talking about some OVN related <br /> guides/sessions but we didn't made any, <br />* networking-midonet - (yet another) stadium project deprecated due to lack of <br /> maintainers, but it's better to have them clearly marked as out of stadium, <br /> than false expectations - we can bring such projects back when needed anyway, <br />* still unstable CI, mainly tempest and tempest-plugin jobs, also during this <br /> release functional tests. <br /><br />As for action items for the _Xena_ cycle, we listed couple of things: <br />* Miguel wants to do the ovn knowledge share internally in his company and <br /> later share the material, <br />* we will keep working on the improvements for our CI, list of all opened, CI <br /> related bugs can be found at <br /> https://tinyurl.com/neutron-gate-failures and we will work on <br /> reducing that list in next months. <br />* Rodolfo and Miguel will follow up on Nova's plans to drop eventlet and move to <br /> the threading and will investigate if we can try to do something similar in <br /> the Neutron, <br />* Akihiro raised good point about ML2/OVN and stadium projects. We should <br /> clarify the support plan for OVN in all of our stadium projects. Lajos and <br /> Lucas volunteered to work on that. <br /><br />### Secure RBAC - testing - discussion with QA team <br />As next session in the first day, we attended QA team's session about testing <br />new secure RBAC policies. Summary of that discussion can be found in the <br />etherpad: https://etherpad.opendev.org/p/qa-xena-ptg. QA team wants to switch <br />each project to enforce new defaults and the system scope tokens in the <br />Devstack. We will have to monitor that and check what needs to be fixed on our <br />side to accomplish that. <br /><br />### Deprecated hybrid plug and the iptables_hybrid firewall driver <br />Bence proposed discussion about potential deprecation of the iptables_hybrid <br />firewall driver as we have now native openvswitch driver too. After discussion <br />we decided that we are not going to deprecate it, at least for now. There are <br />known differences between those two drivers and there is still many usecases <br />where people wants to use iptables_hybrid driver. <br /><br />### Future of the Linuxbridge backend <br />As the last topic of the first day we discussed future of the Linuxbridge <br />backend and ML2 driver. The same topic was discussed in the http://kaplonski.pl/blog/shanghai_ptg_summary/ and then, based on the <br />feedback from operators we decided that we are not going to deprecate this <br />backend anytime soon as many people are still using it. <br />But now we are couple of cycle later and things didn't change a lot. We still <br />don't have anyone who would like to maintain it. In most cases it works fine but <br />there are also pretty many bugs reported for that backend, which don't have <br />owners - see https://tinyurl.com/linuxbridge-bugs. But things may <br />change in the future and e.g. removal of the legacy iptables from the main <br />distributions may makes things harder to work. <br />We again had feedback, e.g. from Jon that NASA is using that driver and want's <br />to keep using it. But from the other hand in the core Neutron we don't have <br />anyone interested in maintaining it currently. <br />The outcome of the discussion is that we will again raise that topic and ask <br />operators about: <br />- who is using it and what are the use cases addressed by that driver - maybe we <br /> can help with proposing another solution, <br />- who is willing to help with maintenance of that backend. <br />If You are using Linuxbridge backend, please give us such feedback. <br /><br />For Xena status is that we still do our best to keep Linuxbridge backend to be <br />running and fully supported but we will also revisit its status again in the <br />next PTG. <br /><br />## Day 2 (Tuesday) <br /><br />### Continuation of "L3 feature improvements" <br />During the second day of the PTG we had very interesting discussions about L3 <br />improvements. We discussed bunch of the RFEs proposed by Bence, Lajos and Manu: <br />* [RFE] Add BFD support for Neutron https://bugs.launchpad.net/neutron/+bug/1907089 <br /> and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/767337<br />* [RFE] Allow explicit management of default routes: https://bugs.launchpad.net/neutron/+bug/1921126) <br /> and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/781475<br />* Allow multiple external gateways on a router: https://bugs.launchpad.net/neutron/+bug/1905295 <br /> and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/779511<br />* [RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers & <br /> bgp-peering from such routers over internal & external Neutron Networks https://bugs.launchpad.net/neutron/+bug/1921461 <br /> and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/783791<br />* [RFE] BFD for BGP Dynamic Routing: https://bugs.launchpad.net/neutron/+bug/1922716<br /> and the spec: https://review.opendev.org/c/openstack/neutron-specs/+/785349.<br /> That one still needs to be discussed and approved during the drivers meeting. <br /><br />General outcome from the discussion is that during the Xena cycle we at least <br />wants to have all those specs merged to have agreement about implementation <br />details. When that will be done, Bence, Lajos and others from Ericsson will work <br />on the implementation of those RFEs. <br /><br />### Tap-as-a-service (taas) project <br />Next topic which we discussed during Tuesday's session was about <br />Tap-as-a-service: https://opendev.org/x/tap-as-a-service project. Few cycle <br />back we were thinking about including it in the Neutron stadium but finally that <br />never really happend. But now both Ericsson and Red Hat are interested in that <br />project so we may want to reconsider that again. <br />During the Xena cycle we will keep it as an unofficial project, but we will also <br />keep an eye on it to see how things will go. <br />We will also investigate if it could maybe be included in the Neutron main <br />repository as a service plugin. That can be easier to do than yet another <br />stadium project to maintain. <br /><br />### OVN support for BGP routing <br />Our next topic on Tuesday was again about BGP, but this time Dan Sneddon from <br />Red Hat shown us idea about new agent to support BGP with ML2/OVN backend. <br />Currently there is no any RFE about that proposed officially for Neutron. This <br />is just an experimental project, completly outside of the official Openstack and <br />Neutron gouvernance. We agreed that next step which Dan and his team will do <br />upstream will be proposal of the RFE and official spec for Neutron to describe <br />this proposal. <br />They will also discuss details of their approach with the Ericsson team which is <br />also doing similar BGP enhancements but for ML2/OVS backend (see above) to <br />hopefully reuse as much as possible between those solutions and to not duplicate <br />code. <br /><br />### Review of the existing blueprints <br />As last topic during second day of the PTG we went through the list of the old, <br />still opened blueprints. We finally decided to close many of them so our backlog <br />is now a bit shorter. List of still opened blueprints can be found at <br />Launchpad: https://blueprints.launchpad.net/neutron/. <br /><br />## Day 3 (Thursday) <br /><br />### OVN as default backend in the Devstack - AMA session for other teams <br /><br />As first topic on Thursday we had Ask Me Anything session for other teams about <br />switch of the default Neutron backend in Devstack from ML2/OVS to ML2/OVN. <br />Lucas made recap of all what was actually done regarding this topic already and <br />what we are still waiting for. <br />We also explained to the people from other teams how such change may (but <br />shouldn't really) impact e.g. their development workflow or CI jobs. <br />We will probably need to work with some teams, like e.g. Kuryr to fix their jobs <br />after switch will be done or to explicitly switch such broken jobs back to the <br />ML2/OVS backend. <br />The other project which will require explicit switch to ML2/OVS backend is <br />networking-sfc which is intended to work only with the ML2/OVS for now. <br />We also agreed that we want to switch it in the Devstack in next 2 weeks. Final <br />patch to do that is proposed already in <br />Gerrit: https://review.opendev.org/c/openstack/devstack/+/735097. <br /><br />### Status of the migration to the "nftables" <br />Rodolfo gave as great recap about current status of the iptables, nftables and <br />legacy APIs in nftables. Currently Neutron works fine with nftables and it's <br />legacy iptables APIs so we should be good even for new distributions which may <br />completly drop old iptables solution. <br /><br />### Secure RBAC policies <br />As next topic on the third day we were reviewing together all of our new <br />default API policies which can be found at https://ethercalc.openstack.org/q9gybzesy246. We had some doubts in <br />few cases but we agreed on how it should be finally. Patches for that are <br />already proposed, and even merged in some cases. <br />This session was recorded and recording is available <br />here: https://zoom.us/rec/share/vEnahdqaGJWiQWl-eN1Jfpr1Uf4v9wdOSTporYgU7VMCKRVYL0y8gBWf0Qgj_LlC._iBB77MB-w9YozL6. <br /><br />### Secure RBAC policies - common session with Nova and Keystone teams <br />It was mostly Nova-Keystone cross project session but there were also topics <br />related to the Neutron so we joined it. <br />We discussed there how to handle system scope tokens, which don't have <br />project_id in the Neutron as almost all resources in Neutron belongs to some <br />project. <br />More detailed summary of that discussion can be found in the policy popup <br />etherpad: https://etherpad.opendev.org/p/policy-popup-xena-ptg.</p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br />## Day 4 (Friday) <br /><br />### Cross project session with Interop WG <br />As a first thing on Friday we had session with Interop working group. Martin <br />Kopec from that group gave as quick recap of what this group is doing and what <br />they would like from our team. We then looked at our new APIs in Neutron and we <br />agreed that "address_groups" is good candidate to be tracked by Interop group as <br />Neutron capability. <br />Based on the guidelines which Martin gave us we will also review our other APIs <br />to see if something else could be added there as well. <br /><br />### Secure RBAC recap <br />This was session done by Lance from Keystone team where he gave us recap of all <br />what was discussed with various teams regarding secure RBAC policies. Details of <br />all those discussions can be found in the policy popup <br />etherpad: https://etherpad.opendev.org/p/policy-popup-xena-ptg. <br /><br />### Cross project session with Nova <br />On the session with Nova we discussed 2 topics: <br />- support guaranteed minimum packet rate QoS policy, <br />- live-migration with MTU change <br /><br />Details of that discussions and agreement on each of the topics can be found in <br />the Nova's etherpad: https://etherpad.opendev.org/p/nova-xena-ptg. <br /><br /><br />### Team photo <br />As last thing on Friday we took team photo (screenshot) which You can see at:</p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><a href="http://kaplonski.pl/images/Virtual_PTG_April_2021/screenshot_1.png">http://kaplonski.pl/images/Virtual_PTG_April_2021/screenshot_1.png</a></p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><u><span style="color:#2980b9;">http://kaplonski.pl/images/Virtual_PTG_April_2021/screenshot_</span></u>2<u>.png</u></p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;"><br />### Summary <br />I want to thank all of You who particpated in the discussions during the <br />Neutron's PTG sessions. It was great and very productive week. We discussed many <br />topics there and I think we have some plan about what we will work on during the <br />Xena cycle. <br />Take care of Yourself and see You online :)<br /><br />This summary is also available at <a href="http://kaplonski.pl/blog/virtual_ptg_april_2021_summary/">http://kaplonski.pl/blog/virtual_ptg_april_2021_summary/</a></p>

<br /><p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">-- </p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Slawek Kaplonski</p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Principal Software Engineer</p>

<p style="margin-top:0;margin-bottom:0;margin-left:0;margin-right:0;">Red Hat</p>

</body>

</html>