14:00:17 <slaweq> #startmeeting networking
14:00:18 <openstack> Meeting started Tue Jan 12 14:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:22 <openstack> The meeting name has been set to 'networking'
14:00:24 <mlavalle> o/
14:00:29 <slaweq> welcome :)
14:00:32 <obondarev> hi all
14:00:56 <amotoki> hi
14:01:12 <bcafarel> o/
14:01:15 <rubasov> o/
14:02:17 <slaweq> ok, lets start
14:02:24 <njohnston> o/
14:02:33 <slaweq> HNY for those who I see first time this year :)
14:02:44 <slaweq> #topic announcements
14:02:55 <slaweq> next week is Wallaby-2 milestone already
14:03:05 <slaweq> we still have couple of specs to review
14:03:10 <ralonsoh> hi
14:03:23 <slaweq> please check and try to review them this week if possible
14:03:44 <slaweq> for now we merged only https://review.opendev.org/c/openstack/neutron-specs/+/739549
14:04:09 <slaweq> and that are all announcements/reminders for today
14:04:17 <slaweq> anything else You want to share with the team?
14:05:54 <slaweq> ok, I guess that this means "no" :)
14:05:57 <slaweq> so lets move on
14:06:02 <slaweq> #topic Blueprints
14:06:10 <slaweq> https://bugs.launchpad.net/neutron/+milestone/wallaby-2
14:06:18 <slaweq> those are things scheduled for wallaby-2
14:06:32 <slaweq> do You have any updates about any of them?
14:07:37 <slaweq> I have update about https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch
14:07:44 <slaweq> we have really all merged in neutron now
14:08:03 <slaweq> I just abandoned old "conclusion" patch which was used to check what is still needed to change
14:08:10 <bcafarel> mission accomplished :)
14:08:15 <slaweq> I also checked stadium projects today
14:08:27 <slaweq> we still have some changes to do in midonet and vpnaas repos
14:08:33 <slaweq> and some minor changes in neutron docs
14:08:45 <slaweq> I will try to push patches this week
14:09:06 <slaweq> so mission is almost accomplished
14:09:22 <ralonsoh> well done
14:09:23 <slaweq> as ralonsoh sum up in some comment - it was (is) 4 years effort :)
14:09:30 <ralonsoh> heheheh
14:09:50 <slaweq> another update, about https://blueprints.launchpad.net/neutron/+spec/secure-bac-roles
14:10:08 <slaweq> we have patches to migrate all our rbac roles to new roles already
14:10:16 <slaweq> https://review.opendev.org/q/topic:%2522secure-rbac%2522+(status:open+OR+status:merged)+project:openstack/neutron,
14:11:00 <slaweq> so please take a look at those patches
14:11:34 <slaweq> we need to check all of them carefully to be able we are not breaking/changing something by mistake
14:12:35 <slaweq> another update, about https://blueprints.launchpad.net/neutron/+spec/default-dns-zone-per-tenant
14:12:44 <slaweq> this is old BP which is almost done
14:12:50 <slaweq> missing patches are:
14:12:53 <slaweq> Neutron patch https://review.opendev.org/#/c/686343/
14:12:56 <slaweq> neutron-tempest-plugin test https://review.opendev.org/#/c/733994/
14:13:01 <slaweq> please take a look at them also
14:13:27 <slaweq> and regarding https://blueprints.launchpad.net/neutron/+spec/address-groups-in-sg-rules
14:13:37 <slaweq> patches are on https://review.opendev.org/#/q/topic:bp/address-groups-in-sg-rules
14:13:48 <slaweq> please add them to the list of Your review queues as well :)
14:14:38 <slaweq> and that's all from my side about BPs
14:16:09 <slaweq> so lets move on to the next topic
14:16:17 <slaweq> #topic Community goals
14:16:29 <slaweq> ralonsoh: amotoki: any updates?
14:16:44 <ralonsoh> still working on the rootwrap deprecation
14:16:52 <ralonsoh> https://review.opendev.org/c/openstack/neutron/+/764015
14:17:10 <ralonsoh> and attempt to migrate, in a generic way, the rootwrap execution
14:17:22 <ralonsoh> I tried to do this in one shot, and it was impossible
14:17:31 <ralonsoh> that's why I'm taking this approach
14:17:43 <ralonsoh> btw, we are executing some long live commands using rootwrap
14:18:04 <ralonsoh> this is incorrect, these executions should be done using a service wrapper
14:18:23 <ralonsoh> I'll try to fix that in next patches
14:18:26 <ralonsoh> (that's all)
14:18:44 <slaweq> ok, a lot of work
14:18:51 <slaweq> if You need any help, please ping me
14:19:00 <ralonsoh> (another 4 years hehehehe)
14:19:04 <ralonsoh> thanks!
14:19:04 <slaweq> LOL
14:19:09 <amotoki> go disconnected...
14:19:26 <amotoki> regarding the policy stuff, https://review.opendev.org/c/openstack/neutron/+/764401 looks a good shape but it needs to pass the gate. I will check the status.
14:20:02 <lajoskatona> Hi
14:20:13 <slaweq> amotoki: thx
14:20:27 <slaweq> this patch is in the check queue now AFAICT
14:20:56 <amotoki> yes
14:21:18 <slaweq> so this should be much faster than ralonsoh's 4 years effort with rootwrap :P
14:21:58 <amotoki> as it is much smaller than the rootwrap one :p
14:22:08 <slaweq> yep :)
14:22:12 <slaweq> ok, lets move on
14:22:14 <slaweq> next topic
14:22:19 <slaweq> #topic Bugs
14:22:40 <slaweq> lajoskatona was our bug deputy 2 weeks ago, his report is at http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019602.html
14:22:46 <slaweq> and amotoki was bug deputy last week
14:22:54 <lajoskatona> yeah that was a quiet week
14:22:55 <slaweq> any bugs You want to highligh here?
14:23:10 <amotoki> I just sent it before the meeting http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019781.html
14:23:13 <amotoki> sorry for late
14:23:14 <lajoskatona> the only one was about security-group operations that are slow
14:23:32 <lajoskatona> and recently there was mail about that on mail/list too
14:23:36 <amotoki> it was a quite week and half of them are about gate failures
14:25:03 <lajoskatona> I think this was the mail: http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019685.html
14:25:22 <amotoki> regaridng the secutiry group issue, is it related to RBAC support in sec group? if so, I think mlavalle's fix improves the performance again
14:26:27 <lajoskatona> as I remember it's not clear from the bug or from the mail, but possible that recent fixes improve the performance
14:26:46 <ralonsoh> I think this is more related to the amount of data you need to transmit to the compute nodes when using FW (as slaweq commented in the mail)
14:26:56 <ralonsoh> I don't see any problem in the DB request
14:27:05 <ralonsoh> (apart from the amount of SG and rules)
14:28:23 <slaweq> the LP bug was more about API request to list SGs
14:28:43 <slaweq> and ML thread was about applying SG rules on compute node
14:28:50 <slaweq> so IMO those are different problems
14:29:03 <slaweq> but maybe I checked different ML thread
14:31:42 <slaweq> I see that LP bug is now marked as "Opinion" and reprorted wrote that will check it on newer version
14:31:57 <slaweq> lets wait for result of that test and we will see if that is still an issue
14:32:13 <lajoskatona> no, you are right, I checked and the mail was to apply rules to VMs on computes  and the lp bug was to list them
14:32:21 <lajoskatona> ok
14:33:51 <slaweq> any other bugs You want to discuss today?
14:34:37 <slaweq> if not, then lets move on
14:34:47 <slaweq> our bug deputy this week is mlavalle
14:34:51 <mlavalle> o/
14:35:07 <slaweq> and next week will be rubasov
14:35:12 <slaweq> rubasov: is that ok for You?
14:35:13 <rubasov> ack
14:35:17 <rubasov> sure
14:35:22 <mlavalle> I have a question
14:35:24 <slaweq> thank You both :)
14:35:25 <mlavalle> though
14:35:27 <slaweq> mlavalle: sure
14:35:29 <slaweq> shoot
14:35:52 <mlavalle> what happens to bugs in the gap between one deputy and the next one
14:36:08 <slaweq> do we have such gaps?
14:36:27 <mlavalle> for example: https://bugs.launchpad.net/neutron/+bug/1910691. Is this amotoki 's report?
14:36:28 <openstack> Launchpad bug 1910691 in neutron "In "test_dvr_router_lifecycle_ha_with_snat_with_fips", the HA proxy PID file is not removed" [Undecided,New]
14:37:06 <ralonsoh> that's mine
14:37:17 <slaweq> this was reported on last Friday so it should be included in amotoki's report usually
14:37:26 <slaweq> maybe he forgot about it :)
14:37:27 <ralonsoh> (sorry, the report)
14:37:53 <mlavalle> so report has to include from Monday to Sunday?
14:37:54 <slaweq> I always though that deputy is for one week, so Monday to Monday more or less
14:38:03 <bcafarel> I see it in http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019781.html
14:38:05 <slaweq> that was my understanding always :)
14:38:11 <bcafarel> mine too :)
14:38:15 <mlavalle> ok
14:38:22 <slaweq> thx bcafarel :)
14:38:27 <mlavalle> let's move on
14:38:27 <slaweq> indeed, it's there
14:38:52 <slaweq> sure, thx for asking mlavalle
14:39:34 <slaweq> ok, so let's move on
14:39:38 <slaweq> #topic On demand
14:39:46 <slaweq> we have one additional topic for today
14:39:53 <slaweq> maybe You already saw thread on ML
14:40:14 <slaweq> but I wanted to see what do You think about Drop (or not) l-c testing --> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019659.html.
14:40:34 <slaweq> I know that tc will be discussing this on their next meeting
14:40:56 <slaweq> but it also seems that projects can make own decisions on that if want
14:41:04 <slaweq> so e.g. oslo dropped it already
14:41:17 <slaweq> wdyt about that in neutron and stadium projects?
14:41:44 <ralonsoh> what's the benefit of l-c testing?
14:41:58 <ralonsoh> apart from checking that we can run Neutron with lowest library versions
14:42:15 <bcafarel> indeed we may get an official "you can all drop it" in a few days, but in the meantime
14:42:28 <slaweq> ralonsoh: I don't have a lot of experience with that but main argument on ML was that it's useful for packaging
14:42:28 <amotoki> one merit is that it detects our lower bounds are correct or not, but I am not sure how the merit is vaulable.
14:42:59 <bcafarel> ack the idea has merit (does neutron actually work with lower versions as mentioned in l-c)
14:43:14 <bcafarel> but until recently the l-c file was not really applicable anyway
14:43:29 <bcafarel> and it is not perfect now either - see recent discussions on ML
14:44:03 <amotoki> yeah, it is usually broken till the improvement in the latest pip resolver came.
14:44:11 <lajoskatona> regarding stadiums most of them have trouble with l-c jobs
14:44:18 <lajoskatona> peridocally we can say :-)
14:44:27 <ralonsoh> and neutron stable versions
14:44:31 <bcafarel> + multiply the effort by number of stable branches
14:44:42 <bcafarel> ralonsoh: :) great minds think alike
14:44:46 <ralonsoh> hehehhe
14:44:49 <slaweq> LOL
14:44:56 <lajoskatona> as I understand it must be periodically maintained, and that is a huge work
14:45:15 <amotoki> IMHO we don't need it for stable branches as we rarely change requirements after the release.
14:45:21 <ralonsoh> I'll say that: we want to drop this CI job
14:46:01 <bcafarel> amotoki: right, plus it does not probably help many people if we fix lower constraints after the release
14:46:24 <slaweq> so You propose to drop this job from stable branches and keep it (for now) in master, right?
14:46:39 <bcafarel> at least first step :)
14:46:49 <amotoki> yes for the stable branches
14:47:01 <slaweq> sounds reasonable for me
14:47:06 <ralonsoh> +1
14:47:07 <obondarev> +1
14:47:19 <bcafarel> I think in master it should probably be thought/redesigned again to be useful, TC opinion should give pointers I think
14:47:22 <lajoskatona> +1
14:48:10 <slaweq> anyone wants to send patches then?
14:48:16 <ralonsoh> I can
14:48:28 <bcafarel> more than motivated to send a few too to kick these out :)
14:48:34 <slaweq> thx
14:48:52 <slaweq> ok, so I think we are good with today's meeting
14:48:56 <amotoki> regarding the master branch, I see a value to some extent. I think the recent situation is a bit different as the new pip resolve was introduced and the inconsistencies were revealed.
14:49:24 <amotoki> that's all from me
14:50:01 <slaweq> thx amotoki
14:50:12 <slaweq> thx for attending the meeting today
14:50:16 <mlavalle> o/
14:50:19 <amotoki> o/
14:50:22 <bcafarel> thanks and HNY!
14:50:22 <ralonsoh> bye
14:50:23 <slaweq> please remember that we have ci meeting in 10 minutes here :)
14:50:25 <slaweq> bye
14:50:27 <slaweq> o/
14:50:29 <slaweq> #endmeeting