Open Stack

Hello Neutrinos:

This is a quick summary of the PTG sessions last week. This is the etherpad
used: https://etherpad.opendev.org/p/neutron-bobcat-ptg

*Retrospective.*

   - Good:
      - Speed on RFE spec reviewal.
      - Continue the deprecation of non-supported code: Linux Bridge,
      neutronclient
      - Good CI tracking of external library dependencies: pyroute2,
      sqlalchemy
      - Good progress on TC goals, in particular sRBAC (now supported in
      Zed).
      - Close of stale bugs
   - Bad:
      - The use of devstack for newcomers, in particular because of
      Neutron. It was proposed to implement vagrant files that will
work with ant
      IDE and will allow to deploy OpenStack easily.
      - Scenario CI jobs still running in Ubuntu Focal due to the nested
      virt provider issues: https://bugs.launchpad.net/neutron/+bug/1999249


   - To be improved:
      - Engagement with students to join the Neutron community


*Stadium projects.*
SQLAlchemy 2.0 is the main problem right now. The CI "-sqlalchmey-master"
jobs should help us to prepare these projects for the next framework
version and we need to start now.
Train branch is broken in most of the CIs. With
https://review.opendev.org/c/openstack/releases/+/878202, all projects will
be migrated to EOL.
networking-odl will be deprecated: it is still testing against ODL 11,
while the latest version is 16. Due to the lack of maintainers, we are no
longer delivering a new release.

*Release cadence.*
New meeting the first Tuesday of each month (Neutron team meeting) to
decide when to release a new project version.
Transition Train to EOL:
https://review.opendev.org/c/openstack/releases/+/878202

*python-neutronclient deprecation.*
Both the CLI and the python bindings code:
https://etherpad.opendev.org/p/python-neutronclient_deprecation
We decided not to spend too much time on this goal, as long as there are
other priorities. But we are going to mark this project as deprecated
(README and mail); that means we'll only push patches for bugs but no new
feature will be accepted. If any project is still using the CLI or the
bindings and needs a new feature, it will need to migrate to SDK (that will
help us on this common effort).

*Port hints feature.*
https://review.opendev.org/q/topic:port-hints
It was considered to use the "tags" resource attribute but this
functionality is very specific to the backend and the property is by
default admin-only. We'll keep the current implementation (under review
right now).

*Stateless security groups.*
This issue was found during the implementation of stateless SG in ML2/OVN.
Main problems:

   - Semantics and mechanics defined in the documentation and the API.
   - DHCP and DHCPv6: as long as other FWs (ML2/OVS native and iptables)
   support both by default with stateless SGs, it will be implicitly supported
   too in ML2/OVN. That will be documented. Rationale: DHCP is a networking
   service and we should be able to provide IP in any case.
   - Metadata: no support. Users will need to explicitly define the
   egress/ingress rules to allow the metadata traffic (as is now in ML2/OVS FW
   drivers).


*IPv6 prefix delegation.*
https://bugs.launchpad.net/neutron/+bug/1895972
It was decided not to implement this feature during this release.
At the same time it was decided to define L3 agent PD feature as
"experimental" because the client used, dibbler, ended the support:
https://bugs.launchpad.net/neutron/+bug/1916428

*Neutron agent status report.*
https://bugs.launchpad.net/neutron/+bug/2011422
It was accepted to have a better report from the agent side of the current
status, including if it was during the initial transient period, if the
agent was doing a full sync, if it was restarted, etc. This functionality
should also provide the ability of reporting customized status for
particular agents.

*DHCP agents with IPv6 metadata services.*
https://bugs.launchpad.net/neutron/+bug/1953165
Several options were considered. The approved one was (3): to schedule a
single IPv6 metadata agent per network, regardless of the HA number of DHCP
agents. That will prevent the IPv6 DAD error now present; the DHCP agent
will use that to stop spawning a new metadata agent (it will consider
another DHCP agent has a running metadata server). No DB/API changes will
be needed.

*sRBAC, phase 2.*
A new role called "service" will be created. It will identify the server to
service calls during the normal operation. For example: Nova to Neutron
port binding activation.
During this cycle we need to identify the server-2-server calls, performed
by other projects against the Neutron API and update these actions with the
new role.

*HWOL API for ports.*
Same topic as commented during the last PTG: the HWOL functionality implies
modifying the port binding, that is an admin-only property (and should
always be like that). Normal users cannot create and request a port with
this functionality if that port was not created before by an admin.
It was also suggested (but at least rejected by me: config driven API is
something now recommended) to have a configuration option to allow the
creation of HWOL ports by default.

*Delete on termination for Neutron ports.*
The goal of this new feature is to mark the port in order to know if it
needs to be deleted after the VM is deleted or not. This functionality is
valid for user created ports, not Nova created ports (the last ones are
always deleted when the VM is).
Nova folks are investigating if "tags" API is valid or not for this RFE. If
not, a new API will be proposed for Neutron ports.

*Allow to specify the hardware model in the Neutron port.*
The goal of this feature is to tint the port with a HW model. For
example "hw_vif_model=virtio"
or "hw_vif_model=e1000".
Same as before, investigate if "tags" is valid or not. We are also
considering improving "tags" to be a key-value model, instead of a list of
strings only.

*Add support for Napatech LinkVirt SmartNICs*
https://review.opendev.org/c/openstack/nova-specs/+/859290
The OVS service is running on the NIC HW. It uses DPDK port representors
(similar to devlink port representors but not present in kernel).
There is a POC in gerrit to be reviewed (patches in the etherpad). The VNIC
type was added some releases ago.
The main issue of this RFE: the lack of CI support. This is why the main
request for this company is to implement an external CI for zuul, adding
some basic tempest tests.

*Port binding activation duplication.*
https://bugs.launchpad.net/neutron/+bug/1986003
It was decided to implement the current solution (
https://review.opendev.org/c/openstack/neutron/+/853281/): if a duplicated
call is received by Neutron, it will raise a Conflict (409) exception,
handled by Nova.

*SR-IOV port tracking in Placement.*
Still under definition. Several alternatives to the current ML2/SRIOV
agent-resource reporting (for QoS) are presented, some of them exclusive to
the current model.
There is a etherpad to track the spec definition:
https://etherpad.opendev.org/p/track-sriov-nics-in-placement

*"skip-level" jobs this cycle (non SLURP).*
It was decided:

   - To continue testing it but testing master against Zed.
   - To move the jobs to experimental and periodic queues.


*ovn-bgp-agent roadmap.*
It was decided to add ovn-bgp-agent to the Neutron stadium. The migration
will be done during this release.
The current API, provided by networking-bgpvpn, is not enough. It is under
consideration to improve it or create a new one, just for OVN. It is also
needed to improve the current documentation: installation, current uses,
drivers available, etc.

*Extend OVN db sync tool.*
Now the OVN DB sync tool removes anything in the OVN NB DB that is not
present in the Neutron DB. That clashes with some deployments, for example
when using the OVN-IC to connect several nodes. E.g.:
http://dani.foroselectronica.es/ovn-cluster-interconnection-567/
It will be proposed a pluggable interface to make the sync tool aware of
these NB objects that have no counterpart in the Neutron DB but in other
OVN DB (ovn-ic-nb, for example).

*FIPS jobs, OS support.*
Currently this functionality is only tested in CentOS8.
CentOS9 has an issue with the conntrack module:
https://bugs.launchpad.net/neutron/+bug/1976323
These jobs are not tested in Ubuntu in the CI because this is a paid
feature.

*Vancouver PTG.*
We have registered the Neutron team for the Vancouver PTG. The topics to be
discussed will be tracked in
https://etherpad.opendev.org/p/neutron-vancouver-2023.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/a666ece1/attachment.htm>