14:00:24 <lajoskatona> #startmeeting neutron_drivers
14:00:24 <opendevmeet> Meeting started Fri Oct  7 14:00:24 2022 UTC and is due to finish in 60 minutes.  The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:24 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:24 <opendevmeet> The meeting name has been set to 'neutron_drivers'
14:00:26 <lajoskatona> o/
14:00:26 <mlavalle> o/
14:00:28 <ralonsoh> hello
14:00:29 <slaweq> o/
14:00:53 <haleyb> o/
14:01:03 <obondarev> hi
14:01:12 <amotoki> o/
14:02:19 <lajoskatona> ok, let's start it
14:02:23 <lajoskatona> We have one RFE for today:
14:02:27 <lajoskatona> [RFE] Strict minimum bandwidth support for tunnelled networks (#link https://bugs.launchpad.net/neutron/+bug/1991965 )
14:02:30 <lajoskatona> from ralonsoh
14:02:46 <ralonsoh> thanks, I have the speech prepared
14:02:47 <ralonsoh> First of all, this RFE will require a spec
14:02:47 <ralonsoh> The goal of this RFE is to provide a mechanism to model the tunnelled networks in a host, same as we do with the different physical interfaces
14:02:47 <ralonsoh> In this case, this is "easier": for each compute node, there will be just one single "local_ip" (where the backend sends the traffic and its a VTEP of the overlay network)
14:02:48 <ralonsoh> How it will work:
14:02:50 <ralonsoh> 1) The agent will report the node tunnelled network BW
14:02:52 <ralonsoh> 2) The port now will create a "resource_request" even if it belongs to an overlay network (now, if the first network segment has no physical network, the resource request is empty)
14:02:55 <ralonsoh> ^^^ caveat: that will change the current behaviour if an active deployment has ports on tunnelled networks with QoS policies and min-BW associated. Now those rules won't apply (not in the backend enforcement nor in the scheduling via Placement)
14:03:38 <yamamoto> hi
14:03:48 <lajoskatona> Hi
14:04:22 <lajoskatona> for this my feeleing from the RFE that nova change is also necessary, ami wrong?
14:04:42 <ralonsoh> not really, the port resource request will request the new trait added
14:05:01 <opendevreview> Lukas Piwowarski proposed openstack/neutron-fwaas master: Remove reference to 'all-plugin' tox environment  https://review.opendev.org/c/openstack/neutron-fwaas/+/860704
14:05:06 <ralonsoh> and the agent will report, at the init time, the tunnelled network BW
14:05:14 <ralonsoh> so the resource provider will be created
14:05:15 <lajoskatona> and nova can do the placement request based on that without change?
14:05:33 <ralonsoh> I'm currently testing this (with OVN) in https://review.opendev.org/c/openstack/neutron/+/860639
14:05:50 <ralonsoh> this is just a 30 mins patch
14:06:05 <opendevreview> Merged openstack/ovn-octavia-provider master: Ensure lbs are properly configured for router gateway set/unset  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/858363
14:06:07 <ralonsoh> and works, placement reserves the BW for the tunneled network
14:06:20 <lajoskatona> suprising :-)
14:06:33 <ralonsoh> this is just a matter of requesting the needed trait
14:07:04 <lajoskatona> sounds cool, I will test it with OVS next week than :-)
14:07:25 <ralonsoh> just with a small change in the OVS agent init method
14:07:47 <ralonsoh> and handling the current 1:1 association between the BW reported and the bridge mapping
14:07:56 <ralonsoh> because in this case there is no bridge
14:08:18 <ralonsoh> --> https://review.opendev.org/c/openstack/neutron/+/860639/1/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/extensions/placement.py#266
14:08:44 <ralonsoh> of course, that will be discussed in the spec
14:09:06 <lajoskatona> +1
14:09:10 <ralonsoh> ah, this is valid for OVN and OVS
14:09:26 <slaweq> +1 from me :)
14:09:38 <lajoskatona> +1 from me also
14:09:44 <ralonsoh> (slaweq has the credit of this idea)
14:09:51 <lajoskatona> a useful generalization of the original feature
14:10:01 <ralonsoh> yeah, some customers asking for this
14:10:16 <ralonsoh> as most of them they are using only vxlan networks
14:10:31 <opendevreview> Merged openstack/neutron stable/yoga: Split Hash Ring probing from the maintenance task  https://review.opendev.org/c/openstack/neutron/+/860563
14:11:11 <lajoskatona> Anybody else do you have any concerns?
14:12:11 <mlavalle> None
14:12:16 <mlavalle> good explanation ralonsoh
14:12:19 <mlavalle> thanks
14:12:21 <haleyb> none from me
14:12:58 <lajoskatona> ralonsoh: you mentioned spec, you are preparing it?
14:13:04 <ralonsoh> right now
14:13:36 <lajoskatona> ok, thanks
14:13:36 <opendevreview> Merged openstack/neutron stable/zed: Split Hash Ring probing from the maintenance task  https://review.opendev.org/c/openstack/neutron/+/860562
14:13:40 <amotoki> does this just ensure the minimum bw for tunnel only on a compute node, right?
14:13:56 <ralonsoh> yes, any tunnelled traffic in one compute node
14:14:05 <amotoki> thanks
14:14:45 <amotoki> I am okay with this proposal
14:14:58 <yamamoto> nothing from me
14:15:29 <mlavalle> it pays to come to the meeting with a "prepared speech"
14:15:32 <lajoskatona> ok, I think we agreed to continue this and accept the RFE, thanks ralonsoh (and slaweq :))
14:15:42 <ralonsoh> thank you all
14:15:51 <slaweq> :)
14:15:59 <lajoskatona> #topic On Demand Agenda
14:16:19 <lajoskatona> I have one (it is not in the agenda as it formed for me today)
14:16:34 <lajoskatona> Nova is in a big refactoring of the PCI stuff handling
14:16:43 <lajoskatona> https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html
14:17:23 <lajoskatona> currently it is ready for the pci handling where neutron is not involved, and they are preparing for doing it for neutron managed sriov/smartnic whatever ports also
14:17:41 <lajoskatona> so this is more a FYI to be prepared for it
14:17:58 <ralonsoh> should we add this topic to the PTG? to the x-team meeting
14:18:05 <lajoskatona> in the spec what I copied there is a section for neutron as not covered currently but with some details how they think now
14:18:10 <mlavalle> ralonsoh: you read my mind
14:18:11 <lajoskatona> ralonsoh: +1
14:18:20 <lajoskatona> that's why I bring this here
14:18:33 <ralonsoh> done, I'll add it (on thursday we'll have those meetings)
14:18:41 <mlavalle> +1
14:18:42 <lajoskatona> cool
14:18:48 <ralonsoh> (on monday I'll update the scheduling)
14:18:56 <lajoskatona> that's all from me
14:19:31 <lajoskatona> Do you have anything more to discuss?
14:19:37 <slaweq> nope
14:20:04 <mlavalle> so, next drivers meeting will be chaired by ralonsoh
14:20:15 <lajoskatona> yes, good topic :-)
14:20:25 <ralonsoh> yeah, I think it is time
14:20:27 <lajoskatona> this week I forgot to push this on his back :-)
14:20:36 <ralonsoh> I'll take care of this meeting since the next week
14:20:39 <mlavalle> well, thank you for leading us this past year lajoskatona !!!
14:20:46 <ralonsoh> lajoskatona++ thanks a lot!
14:20:47 <mlavalle> you did a great job
14:20:50 <amotoki> lajoskatona: thanks a lot
14:20:52 <lajoskatona> :-)
14:21:00 <lajoskatona> I tried my best
14:21:04 <slaweq> lajoskatona++ thx for leading this meeting for long time
14:21:08 <lajoskatona> it was really good experience
14:21:41 <mlavalle> and welcome to our new Fearless Leader, ralonsoh!
14:21:56 <lajoskatona> Yeayyyy
14:22:01 <ralonsoh> thanks
14:22:30 <lajoskatona> If nothing more we can close the meeting
14:22:46 <slaweq> \o/
14:22:49 <ralonsoh> have a nice weekend
14:22:52 <lajoskatona> #endmeeting