- 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.
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.
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.
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.
It was decided not to implement this feature during this release.
Neutron agent status report.
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.
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
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.
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.
"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.
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.
These jobs are not tested in Ubuntu in the CI because this is a paid feature.
Vancouver PTG.
Regards.