<div dir="ltr"><div dir="ltr"><div>Hello Neutrinos:</div><div><br></div><div>This is a quick summary of what we have discussed during the PTG week.<br></div><div></div><div><br></div><div><div>Zed summary and retrospective: <br></div><div><ul><li>Here is the output of this session: <a href="https://etherpad.opendev.org/p/neutron-antelope-ptg#L83" target="_blank">https://etherpad.opendev.org/p/neutron-antelope-ptg#L83</a></li></ul></div></div><div><br></div><div>Spec handling:</div><div><ul><li>To
 have a core reviewer assigned per spec. This reviewer will engage the 
community to review the spec and will be a kind of "godfather".</li><li>To
 have a weekly status report of the active specs in the community, to 
visibilize them, boost their impact and "coerce" the community to review
 them.</li></ul><div><br></div><div>Neutron CLI deprecation:</div><div><ul><li>To remove the CLI code.</li><li>Python bindings:<br></li><ul><li>Investigate and report the effort needed to make this migration in neutron client consumers (Nova, Horizon, Heat, etc).<br></li><li>Request other projects using the python bindings to move to OpenStack SDK.</li><li>Stop merging new features.<br></li></ul></ul></div></div><div><br></div><div>Quota classes:</div><div><ul><li>Information: <a href="https://docs.openstack.org/project-team-guide/technical-guides/unified-limits.html" target="_blank">https://docs.openstack.org/project-team-guide/technical-guides/unified-limits.html</a></li><li>Neutron RFE: <a href="https://bugs.launchpad.net/neutron/+bug/1993288" target="_blank">https://bugs.launchpad.net/neutron/+bug/1993288</a></li><li>Still
 under development in the community, this is still not an accepted 
community goal, thus we won't start the development until some cons are 
discussed with the TC members (see the Neutron RFE description).</li></ul><div><br></div><div>Pyroute2 session:</div><div><ul><li>IPmock, a new class to mock some pyroute2 objects: <span><a href="https://lab.pyroute2.org/" rel="noreferrer noopener" target="_blank">https://lab.pyroute2.org/</a></span></li><li><span>Pluggable netlink engines. Still not compatible with NetNS (namespaces)</span></li><li><span>Transactional engine:</span></li><ul><li><span>A
 daemon is always reading the netlink and inotify, and builds a DB with 
the system information. Data is read faster. This could be not 
compatible with the current sync calls using privsep.<br></span></li><li><span>Using NDB class.</span></li></ul><li><span>Customize message parser, to reduce the amount of data retrieved from the kernel.</span></li><li><span>Dump/list operators will be generators (to check the compatibility with privsep).</span></li></ul><div><br></div><div>Remove
 the failed devstack migration and get back to what is called 
"neutron-legacy" (that was discussed before in a PTG but we didn't start
 the reversion).<br></div></div><div><br></div><div><span id="m_-6458952393014847150m_-1611456880719363181gmail-output">DNS subdomain support in ML2/OVN</span>:</div><div><ul><li><a href="https://review.opendev.org/c/openstack/neutron-specs/+/832658" target="_blank">https://review.opendev.org/c/openstack/neutron-specs/+/832658</a></li><li>On hold until there is a use case.</li></ul><div><br></div><div>DNS resolver in ML2/OVN:</div><div><ul><li><a href="https://bugzilla.redhat.com/show_bug.cgi?id=2104568" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=2104568</a></li><li>The main devoplment part falls in the OVN core team. Once finished, the Neutron part should be almost trivial.</li></ul><div><br></div><div>ML2/OVN flow metering.</div><div><ul><li>Same
 as we currently have with ML2/OVS + iptables firewall (currently not 
supported with native firewall because we can't count OF flows).</li><li>Same as the previous feature, the main development is in the OVN core team.</li></ul><div><br></div><div>Neutron QA:</div><div><ul><li>Implement a grenade job based on the SLURP cadence, testing from Y to A (done).</li><li>Have the "tempest-integrated-networking" job in our gate/check queues (patch under review).<br></li></ul></div></div><div><br></div><div><span>PCI Device Tracking In Placement (Nova-Neutron session):</span></div><div><ul><li>The different approaches are still under development.</li><li>Spec to be proposed during this release (see etherpad to check the possible implementation options).</li></ul><div><br></div><div>Port binding <span>switchdev capabilities <span>(Nova-Neutron session)</span>:</span></div><div><ul><li>We
 agreed that the current implementation is incorrect: Neutron should not
 modify the port binding dictionary. Nova is not reading it but 
overwriting it.</li><li>We won't change the current code but no new features will rely on it.</li></ul><div><br></div><div><span>Nova mutable MTU support <span>(Nova-Neutron session):</span></span></div><div><ul><li>For
 now, Neutron will document that a network MTU change requires a VM 
reboot (ot port detach/attach operations) to be applied on this port.</li></ul><div><br></div><div><span>S-RBAC:</span></div><div><ul><li>Neutron has three implemented personas: system wide admin, project user and project reader.</li><li>Tempest will integrate all RBAC testing projects during this release. Once done, the new RBAC flag will be enabled by default.</li><li>Neutron will create the corresponding RBAC job/jobs.</li><li>Neutron
 needs to identify what is called "service role" calls (done from other 
projects). This is a new concept that will be included in next releases.</li></ul><div><br></div><div>nftables migration:</div><div><ul><li>The
 current iptables legacy interface could be deprecated. During this 
release, Neutron will start an epic to move the current iptables API to 
the new nftables API; if possible, incrementally, mixing both APIs in 
the same agent.</li></ul><div><br></div><div>Please, if there is any missing topic, let me know.<br></div><div><br></div><div>Regards and thank you for attending and participating.</div><div><br></div></div></div></div></div></div></div></div></div></div></div>