Open Stack

Hi,

I will try to summarize the Neutron PTG sessions during the last week.
The etherpad which we used: https://etherpad.opendev.org/p/neutron-zed-ptg

# Day 1 (Monday April 4.)
## Yoga retrospective (I just list here the topics, not every discussion
under them):
* Good things
** New active people around the team
** Revived project: neutron-fwaas
** video CI meetings every second week are very good IMO
** OVN backend is getting more and more attention and there are less gaps
between OVN and OVS backends
* Bad / Not so good:
** less and less active people
** to much depends on Red Hat - ~66% of reviews, ~62% of commits (in
Neutron official projects)
** lack of maintainers for some stadium projects (neutron-vpnaas) and some
backends/drivers (linuxbridge)

* As action we previously decided to have a forum session during the Berlin
Summit to discuss the lack of activity/maintainers for some backends and
stadium projects hopefully with some operators also.

## Short update on bgp related blueprints
https://etherpad.opendev.org/p/neutron-zed-ptg#L111
The development of these blueprints are stopped, we will revert the already
merged code.

# Day 2 (Tuesday April 5.)
## Have nova / os-vif delete the trunk bridges to avoid race conditions
The creation of trunk bridges now done by os-vif, and the deletion is done
by Neutron, to avoid the race condition we agreed to have both operations
done by os-vif.

## skip-level upgrade (tick-tick)
We discussed together how this affects Neutron, what is working currently
and what is in front of us.
We have periodic jobs for ovs and ovn backend.
Actions:
* Make ovn grenade upgrade jobs green

## When we say something is not supported?
* Recently from the  Neutron stadium neutron-vpnaas project was that lost
all maintainers. Neutron core team keeps an eye on the gate of networking
projects, and keep them green, but if there is nobody with specific
knowledge for the given area we can't solve the bugs.
* We have similar problems with "in-tree" drivers also, a good example is
the linuxbridge driver.

Agreement was to keep the current approach for stadium project, so send out
mail to openstack-discuss, asking for help, and if nobody appears, make the
project retired and delete the code but keep git history for it.
For in-tree code (drivers, extensions....):
* We keep existing jobs for linuxbridge driver for example, but when the
tests start to fail we skip them and finally we stop the job also.
To make it clear for operators we add warning logs highlighting that the
given feature/driver is experimental, and introduce cfg option to enable
such features explicitly.
We plan to discuss these questions during the Berlin Summit with operators.

## Prefix delegation for Openstack Neutron aka: dibbler tool for dhcpv6 is
concluded
The original bug: https://bugs.launchpad.net/neutron/+bug/1916428
* The tool behind PD, Dibbler is no more maintained and the suggested tool
ISC Kea has no DHCP client actually.
* this feature is not tested in upstream CI
Due to these we decided to mark prefix delegation as experimental feature.

# Day 3 (Wednesday April 6.)
## neutron-dynamic-routing + OVN
Redhat works on a BGP solution for OVN, that is ovn-bgp-agent, and
currently it doesn't need the existing API in neutron-dynamic-routing.
The current approach to make neutron-dynamic-routing work with OVN will be
checked.

## Option for OVN to disable DHCP/DNS and use dhcp-agent instead
Technically it is possible, a new RFE will be proposed and the drivers team
will discuss the usecase behind it.

## CI status / zuul job config errors

In the list of zuul cfg errors (
https://zuul.opendev.org/t/openstack/config-errors ) old Neutron stadium
branches are listed.
* Decision was to EOL these old branches where fixing is not possible.

Another topic was from Slawek if we want to have
neutron-tempest-plugin-api-ovs job, and the agreement was to merge OVS
scenario and API jobs.

## inconsistencies in OVS firewall on an agent restart

We will go for a cfg option to select between OVS flow installation in
batches and per port, and operators can select which is best for their
environment.

## Pain Points

TC started a discussion to cover the collected operator pain points, last
week we checked again the list for Neutron (
https://etherpad.opendev.org/p/pain-point-elimination#L268):
* neutron (via python calls) and OVN (via C calls) can have different ideas
about what the hostname is, particulary if a deployer (rightly or wrongly)
sets their hostname to be an FQDN
** it was fixed:
https://review.opendev.org/q/Iea2533f4c52935b4ecda9ec22fb619c131febfa1

* Useful error msg when network deletion fails due to existing resources on
it
** done: https://review.opendev.org/c/openstack/neutron/+/821935

* Open vSwitch Agent excess logging at INFO level
** we check if we can change some to debug, Slawek create a DNM job with
only info logs to discuss during one of the coming meetings.

* OVN: Spoofing of DNS reponses seems very wrong behavior
** We agreed that for this we need an RFE (see above for disabling OVN
DNS/DHCP)

## Edge topics

Together with the Designate team we agreed that this is more a
documentation problem based on our current understanding. Based on Redhat
downstream bugs for edge deployments we try to cover these in this cycle.

# Day 4 (Thursday April 7.)

We have no sassions.

# Day 5 (Friday April 8.)

## Nova - Neutron xproject

### How to require ml2 plugins to implement multiple port bindings
The problem is that there are old drivers (hyperv perhaps and others) that
do not implement it and this cause a lot of extra code path in Nova.
Sean suggested a Forum topic for Berlin to discuss it with operators also.

### Is heal_instance_info_cache_interval still needed?
Let's create a job which sets heal_instance_info_cache_interval to 0, and
decide the next steps based on the results.

The happy moment with the team screenshot:
https://photos.app.goo.gl/P6YuYgxzqEiv2gHt8
I hope next time we can meet in person :-)

Thanks to everybody for the great discussions.

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220413/4ad9877f/attachment.htm>