14:00:26 <slaweq> #startmeeting networking
14:00:27 <openstack> Meeting started Tue Jan 19 14:00:26 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'networking'
14:00:34 <mlavalle> o/
14:00:35 <slaweq> hi
14:00:37 <_erlon_> \o
14:00:40 <obondarev> hi
14:00:42 <lajoskatona> o/
14:00:46 <radez> o/
14:01:12 <bcafarel> \o
14:01:13 <rubasov> o/
14:01:19 <slaweq> I think we can start
14:01:21 <slaweq> #topic announcements
14:01:31 <slaweq> This week is W-2 milestone, next milestone will be in March 8th
14:01:45 <slaweq> as for W-2 itself we don't have any todo actions strictly
14:02:03 <slaweq> but I think we should do new releases of stable branches
14:02:05 <slaweq> wdyt?
14:02:20 <ralonsoh> hi
14:02:44 <mlavalle> yeah, let's do it
14:02:56 <bcafarel> sounds good, we said we would do such releases around milestones
14:03:06 <bcafarel> and we have that api fix for security groups finally merged too
14:03:08 <mlavalle> part of the process if I remember correctly
14:03:13 <slaweq> especially that we have finally https://review.opendev.org/q/510089bc5fc08b81df24e67923000e5c56dfda66 merged
14:03:17 <slaweq> mlavalle: yep
14:03:33 <slaweq> ok, I will propose new releases this week
14:03:47 <slaweq> or bcafarel, maybe You want to do that? :)
14:04:32 <bcafarel> slaweq: sure let me check the pending backports, to see if some would be nice in tagged releaes
14:04:36 <bcafarel> *releases
14:04:40 <slaweq> bcafarel++ thx a lot
14:04:58 <slaweq> lets sync about it later this week in neutron channel
14:05:17 <slaweq> ok, next one
14:05:21 <slaweq> stein EM, now we have stein-last tag in neutron-tempest-plugin also: https://review.opendev.org/c/openstack/releases/+/768553
14:05:42 <slaweq> and we also just merged patch to drop stein jobs from neutron-tempest-plugin queues
14:06:11 <slaweq> those jobs will work always with that tag and only on patches proposed to stable/stein branch in Neutron now
14:06:44 <slaweq> and the last one
14:06:49 <slaweq> regarding OSC/SDK
14:06:54 <slaweq> I started work on SDK/OSC patches to allow "unknown parameters" there, please check https://review.opendev.org/c/openstack/openstacksdk/+/768208 and https://review.opendev.org/c/openstack/python-openstackclient/+/768210 and tell me if that makes sense for You so I will continue that work
14:07:14 * slaweq will be back in 5 minutes
14:10:46 * slaweq is back
14:10:49 <slaweq> sorry
14:10:51 <slaweq> ok, lets move on
14:10:59 <slaweq> that's all announcements from me today
14:11:09 <slaweq> do You have anything else to share with the team?
14:12:01 <bcafarel> seems like a no :)
14:12:18 <slaweq> ok, lets move on then
14:12:24 <slaweq> #topic Blueprints
14:12:35 <slaweq> https://bugs.launchpad.net/neutron/+milestone/wallaby-2
14:12:44 <slaweq> any updates about BPs?
14:13:30 <lajoskatona> slaweq: regarding https://bugs.launchpad.net/bugs/1882804
14:13:32 <openstack> Launchpad bug 1882804 in neutron "RFE: allow replacing the QoS policy of bound port" [Wishlist,Confirmed] - Assigned to Lajos Katona (lajos-katona)
14:13:47 <lajoskatona> Some final things moving there to merge the tempest tests for it
14:14:00 <lajoskatona> so slowly but moving forward
14:14:22 <slaweq> thx lajoskatona
14:14:31 <slaweq> I saw today that gmann is ok with Your tempest patch
14:14:45 <slaweq> but it requires some backports to devstack's stable/train and ussuri, right?
14:14:57 <lajoskatona> yeah the last patch is on its way for devstack to skip these tests on older branches
14:15:04 <slaweq> great
14:15:14 <slaweq> thx for update
14:15:48 <slaweq> any other updates?
14:16:37 <slaweq> mlavalle: qq about address groups in SG
14:16:44 <slaweq> list of patches is here https://review.opendev.org/q/topic:bp/address-groups-in-sg-rules
14:16:46 <mlavalle> ok
14:16:53 <slaweq> are those all patches needed to close this BP?
14:17:01 <slaweq> I think so, but maybe I'm missing something
14:17:13 <mlavalle> those are the ones we need to close the BP
14:17:38 <slaweq> ok, so we are almost there :)
14:17:48 <mlavalle> yeap
14:17:51 <slaweq> thx
14:17:55 <mlavalle> we are testing the fw patch
14:18:45 <slaweq> regardig engine facade: https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
14:18:57 <slaweq> last week I proposed patches for midonet and vpnaas:
14:19:01 <slaweq> networking-midonet: https://review.opendev.org/c/openstack/networking-midonet/+/770797
14:19:03 <slaweq> neutron-vpnaas: https://review.opendev.org/c/openstack/neutron-vpnaas/+/770800
14:19:14 <slaweq> and ralonsoh made patch for neutron docs: https://review.opendev.org/c/openstack/neutron/+/770826
14:19:24 <slaweq> those are I think last 3 things needed to close this BP
14:19:34 <slaweq> but I see that midonet's gate is totally broken now :/
14:20:26 <bcafarel> that's a lot of red :(
14:20:32 <slaweq> regarding https://blueprints.launchpad.net/neutron/+spec/secure-rbac-roles
14:20:42 <slaweq> patches https://review.opendev.org/q/topic:%2522secure-rbac%2522+(status:open+OR+status:merged)+project:openstack/neutron,
14:20:50 <slaweq> so far we merged only few of them
14:21:06 <slaweq> I will go through them this week to check why zuul gave -1 for some
14:21:15 <slaweq> and will try to fix issues if there will be any
14:21:26 <slaweq> but please also review those patches if You have some time :)
14:21:54 <slaweq> regardin https://blueprints.launchpad.net/neutron/+spec/default-dns-zone-per-tenant - there is last missing patch to be merged: https://review.opendev.org/#/c/686343/
14:22:04 <slaweq> please add it to Your review list :)
14:22:32 <slaweq> and that are all updates from me for today
14:22:46 <slaweq> I think we can move on
14:24:28 <slaweq> ok, lets move on
14:24:38 <slaweq> #topic Community Goals
14:24:55 <slaweq> any updates about privsep or rbac policy format?
14:25:24 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/764015
14:25:34 <ralonsoh> migrating slowly to privsep
14:25:47 <ralonsoh> I'll push new patches on top of this one
14:25:48 <ralonsoh> thanks!
14:26:10 <slaweq> ok, thx ralonsoh
14:27:02 <slaweq> regarding policy.json -> policy.yaml, neutron patch is in the gate now so we should be good soon
14:27:09 <slaweq> ok, lets move on
14:27:14 <slaweq> #topic Bugs
14:27:22 <slaweq> mlavalle was bug deputy last week
14:27:39 <slaweq> report: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019878.html
14:27:44 <mlavalle> we had some bugs, but not a lot
14:27:46 <slaweq> mlavalle: any bugs You want to discuss?
14:28:20 <mlavalle> https://bugs.launchpad.net/neutron/+bug/1911214
14:28:21 <openstack> Launchpad bug 1911214 in neutron "Scenario test test_multiple_ports_secgroup_inheritance fails in ovn scenario job" [Medium,Confirmed]
14:28:25 <mlavalle> needs owner
14:28:40 <jlibosva> I saw otherwiseguy started looking at that one but if needed, I can also take a look
14:28:54 <mlavalle> and also https://bugs.launchpad.net/neutron/+bug/1911132
14:28:56 <openstack> Launchpad bug 1911132 in neutron "OVN mech driver - can't find Logical_Router errors" [Medium,Confirmed]
14:29:04 <jlibosva> sorry, it's the other bug :) ignore me
14:29:11 <mlavalle> I thought so
14:29:16 <mlavalle> he made comments to it
14:30:07 <mlavalle> and https://bugs.launchpad.net/neutron/+bug/1911864 is a potential new RFE
14:30:08 <openstack> Launchpad bug 1911864 in neutron "[DHCP] AgentBinding for network will be created no matter the state" [Wishlist,Triaged]
14:30:25 <mlavalle> THat's all I have to comment
14:30:36 <otherwiseguy> yeah, I haven't had much chance to look at that one yet.
14:31:34 <slaweq> thx mlavalle
14:31:41 <slaweq> I will check that rfe this week
14:32:54 <slaweq> jlibosva: otherwiseguy: can You take care of the ovn related bugs mentioned by mlavalle?
14:33:22 <jlibosva> slaweq: yes, we'll assign that to ourselves and will try to fix it
14:33:32 <otherwiseguy> +1
14:33:37 <slaweq> jlibosva otherwiseguy thx a lot
14:34:02 <slaweq> ok, any other bugs You want to discuss today?
14:34:20 <slaweq> and thx mlavalle for being bug deputy and for Your report :)
14:34:34 <mlavalle> :-)
14:36:14 <slaweq> ok, I guess that there is no other bugs to discuss today
14:36:25 <slaweq> this week our bug deputy is rubasov
14:36:33 <slaweq> and he's already aware of it :)
14:36:38 <slaweq> thx rubasov
14:36:46 <rubasov> of course
14:36:50 <slaweq> next week it will be ralonsoh's turn
14:36:57 <ralonsoh> perfect
14:37:17 <slaweq> ok, so lets go to the last topic for today
14:37:21 <slaweq> #topic On Demand Agenda
14:37:36 <slaweq> _erlon_: hi, You added topic there
14:37:47 <slaweq> so please speak now :)
14:37:53 <_erlon_> slaweq: hey guys
14:37:57 <_erlon_> thanks for having me here
14:39:05 <_erlon_> so, I have some use cases where an Octavia user needs to update its listeners with a lot of addresses
14:39:36 <_erlon_> and that ends up in Octavia sending thousands of security group port updates to neutron
14:39:58 <_erlon_> and therefore the performace gets poor as the number of listeners increases
14:40:18 <_erlon_> so, I was wondering if this was something discussed in the past
14:41:00 <_erlon_> and how the Neutron team would view the idea of having support for bulk requests on the security group ports
14:41:37 <slaweq> _erlon_: but do You mean that You need to put many SG rules to allow traffic to/from many IP addresses?
14:41:47 <slaweq> so You are adding one rule per IP address?
14:41:50 <slaweq> is that correct?
14:41:50 <_erlon_> exactly
14:41:55 <_erlon_> yes
14:41:59 <_erlon_> thats correct
14:42:05 <slaweq> can You check address groups https://blueprints.launchpad.net/neutron/+spec/address-groups-in-sg-rules ?
14:42:12 <_erlon_> and the addresses came from differenc CIRD
14:42:13 <slaweq> maybe that would solve Your use case
14:42:41 <slaweq> so You would be able to have one rule and update address group there
14:42:55 <_erlon_> ow, that is fresh
14:43:03 <slaweq> yes, it's not fully implemented yet
14:43:25 <slaweq> but creation of SG rules in bulk aren't implemented neighter :)
14:44:22 <mlavalle> yeah, I was going to mention address groups
14:44:33 <mlavalle> we want to finish this implementation this cycle
14:45:20 <_erlon_> ok, Ill read the specs and see where a bulk api would/if fit
14:45:36 <slaweq> _erlon_: ok
14:45:44 <slaweq> I'm not agains adding bulk api for SG rules
14:45:51 <slaweq> this may still be useful
14:45:54 <_erlon_> but the most important to me is to know if that is not something completly aliean for Neutron and that people would have some acceptance to the idea
14:46:43 <slaweq> we have bulk operations for e.g. ports already
14:47:00 <slaweq> so IMO we can have it also for other resources
14:47:25 <slaweq> but IIRC implementation of it for ports wasn't trivial
14:47:34 <slaweq> so for SG rules it may be similar
14:48:05 <_erlon_> ok, its something to get started
14:48:40 <slaweq> if You will want to work on that bulk SG rules API, please open RFE on launchpad and we can discuss that there
14:48:58 <slaweq> is that fine answer for You for now?
14:49:57 <_erlon_> ok, Ill discuss this with our software team then, get back once/if we have a slot in our development cicles for that
14:50:08 <_erlon_> slaweq: yes, thanks a lot
14:50:15 <slaweq> _erlon_: thx
14:50:21 <slaweq> any other topics for today?
14:50:31 <slaweq> if not I will give You few minutes back today
14:51:34 <slaweq> ok, I guess this means "no", so thx for attending the meeting and see You online
14:51:37 <slaweq> o/
14:51:41 <ralonsoh> bye
14:51:42 <slaweq> #endmeeting