[neutron] Antelope PTG summary

Rodolfo Alonso Hernandez ralonsoh at redhat.com
Tue Oct 25 11:00:10 UTC 2022

Hello Neutrinos:

This is a quick summary of what we have discussed during the PTG week.

Zed summary and retrospective:

   - Here is the output of this session:

Spec handling:

   - 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".
   - 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

Neutron CLI deprecation:

   - To remove the CLI code.
   - Python bindings:
   - Investigate and report the effort needed to make this migration in
      neutron client consumers (Nova, Horizon, Heat, etc).
      - Request other projects using the python bindings to move to
      OpenStack SDK.
      - Stop merging new features.

Quota classes:

   - Information:
   - Neutron RFE: https://bugs.launchpad.net/neutron/+bug/1993288
   - 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).

Pyroute2 session:

   - IPmock, a new class to mock some pyroute2 objects:
   - Pluggable netlink engines. Still not compatible with NetNS (namespaces)
   - Transactional engine:
      - 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.
      - Using NDB class.
   - Customize message parser, to reduce the amount of data retrieved from
   the kernel.
   - Dump/list operators will be generators (to check the compatibility
   with privsep).

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).

DNS subdomain support in ML2/OVN:

   - https://review.opendev.org/c/openstack/neutron-specs/+/832658
   - On hold until there is a use case.

DNS resolver in ML2/OVN:

   - https://bugzilla.redhat.com/show_bug.cgi?id=2104568
   - The main devoplment part falls in the OVN core team. Once finished,
   the Neutron part should be almost trivial.

ML2/OVN flow metering.

   - Same as we currently have with ML2/OVS + iptables firewall (currently
   not supported with native firewall because we can't count OF flows).
   - Same as the previous feature, the main development is in the OVN core

Neutron QA:

   - Implement a grenade job based on the SLURP cadence, testing from Y to
   A (done).
   - Have the "tempest-integrated-networking" job in our gate/check queues
   (patch under review).

PCI Device Tracking In Placement (Nova-Neutron session):

   - The different approaches are still under development.
   - Spec to be proposed during this release (see etherpad to check the
   possible implementation options).

Port binding switchdev capabilities (Nova-Neutron session):

   - We agreed that the current implementation is incorrect: Neutron should
   not modify the port binding dictionary. Nova is not reading it but
   overwriting it.
   - We won't change the current code but no new features will rely on it.

Nova mutable MTU support (Nova-Neutron session):

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


   - Neutron has three implemented personas: system wide admin, project
   user and project reader.
   - Tempest will integrate all RBAC testing projects during this release.
   Once done, the new RBAC flag will be enabled by default.
   - Neutron will create the corresponding RBAC job/jobs.
   - 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

nftables migration:

   - 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

Please, if there is any missing topic, let me know.

Regards and thank you for attending and participating.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221025/8b16f849/attachment-0001.htm>

More information about the openstack-discuss mailing list