14:00:13 <slaweq> #startmeeting networking 14:00:13 <openstack> Meeting started Tue Nov 17 14:00:13 2020 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:17 <openstack> The meeting name has been set to 'networking' 14:00:31 <njohnston_> o/ 14:00:43 <mlavalle> o/ 14:00:54 <slaweq> o/ 14:01:05 <bcafarel> o/ 14:01:07 <obondarev> hi 14:01:14 <rubasov> o/ 14:02:24 <haleyb> hi 14:03:01 <slaweq> #topic Announcements 14:03:23 <slaweq> I don't have many announcements for today 14:03:32 <slaweq> just 2 reminders 14:03:46 <slaweq> Wallaby-1 milestone is just in 2 weeks so we are close to it 14:03:51 <slaweq> and second 14:04:09 <slaweq> this weekend gerrit outage is planned: http://lists.opendev.org/pipermail/service-announce/2020-October/000012.html 14:04:26 <slaweq> please be aware of it if You want to work on something during those days ;) 14:04:50 <slaweq> anything else You want to share with the team? 14:05:48 <ralonsoh> (sorry I'm in other meeting) 14:06:49 <slaweq> ok, I guess that this means "no" :) 14:06:52 <slaweq> and we can move on 14:07:01 <slaweq> #topic Blueprints 14:07:16 <slaweq> Wallaby-1 https://bugs.launchpad.net/neutron/+milestone/wallaby-1 14:07:23 <slaweq> any updates about any of BPs? 14:07:56 <mlavalle> We continue working on address groups. Couple of patches will be coming soon 14:08:35 <slaweq> mlavalle: and one of them is actually blocked by https://review.opendev.org/#/c/762434/ 14:08:41 <slaweq> right? 14:09:01 <mlavalle> That's a third one 14:09:27 <mlavalle> the API and DB patch for address groups in security group rules 14:09:33 <slaweq> I will check obondarev's comments there later today and will try also to check why it's still not working as it should 14:09:39 <slaweq> so hopefully it will be ready this week 14:09:41 <mlavalle> Thanks! 14:10:37 <slaweq> any other updates? 14:11:41 <slaweq> ok 14:11:47 <slaweq> I have 2 quick updates 14:13:45 <slaweq> 1. I closed BP related to the db retries as that's what we decided on the last drivers meeting 14:13:53 <slaweq> https://blueprints.launchpad.net/neutron/+spec/handle-deadlocks-in-oslo-way 14:14:06 <lajoskatona> Hi 14:14:36 <slaweq> 2. I was pinged today by xinranwang who asked me about review of https://review.opendev.org/#/c/742785/ 14:14:51 <slaweq> it is nova spec, but it has also some parts related to the neutron 14:14:58 * bcafarel notes to read last drivers' meeting log 14:14:58 <slaweq> that's at least what he told me 14:15:23 <slaweq> so, please add this spec to Your review list and check it 14:16:41 <slaweq> and that's basically all from my side regarding BPs 14:17:22 <slaweq> if there are no other updates, lets move on 14:17:31 <slaweq> #topic Community Goals 14:17:45 <slaweq> Migrate from oslo.rootwrap to oslo.privsep driven by ralonsoh 14:18:06 <slaweq> I started preparing some list of changes which we need to do here to accomplish that 14:18:12 <slaweq> I didn't finish it yet 14:18:22 <slaweq> but I have a question to all of You 14:18:36 <slaweq> I found in neutron tree module: neutron/agent/linux/xenapi_root_helper.py 14:18:59 <slaweq> my question is: do we still should keep it there? is it used by anyone? 14:19:13 <slaweq> I don't think we are doing any kind of testing of it really 14:19:18 <ralonsoh> it was removed in Nova: https://review.opendev.org/#/c/749309/, https://review.opendev.org/#/c/749304/ 14:19:27 <slaweq> thx ralonsoh 14:20:40 <ralonsoh> I think we should mark the conf options as deprecated and remove all the code 14:20:51 <ralonsoh> and in X, remove the conf options 14:20:58 <njohnston> +1 14:21:35 <bcafarel> cleanup++ 14:22:06 <obondarev> +1 14:23:41 <slaweq> do You think that we should first send email to ML to ensure that nobody is using it really? 14:24:06 <lajoskatona> +1 14:24:49 <ralonsoh> I don't think so 14:24:54 <ralonsoh> that was sent 1 year ago 14:25:02 <njohnston> personally I think we can go by the due diligence nova would have done before deprecating their part 14:25:03 <ralonsoh> then Nova marked it as deprecated 14:25:09 <ralonsoh> in 2019 14:25:21 <slaweq> ok 14:25:31 <slaweq> great :) 14:25:37 <slaweq> any volunteer to do that? 14:25:42 <ralonsoh> I'm on it now 14:25:47 <slaweq> ralonsoh: thx a lot 14:26:13 <slaweq> any other updates regarding community goals? amotoki, ralonsoh? 14:26:24 <ralonsoh> no, thanks 14:26:36 <amotoki> no update this week 14:26:46 <slaweq> ok, lets move on then 14:26:52 <slaweq> #topic Bugs 14:27:19 <slaweq> lucasgomes was bug deputy: http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018782.html 14:27:36 <slaweq> I went through this list today 14:27:52 <slaweq> and I think there is couple of bugs which needs some attention 14:28:07 <slaweq> first of all, 2 bugs related to stable branches 14:28:09 <slaweq> https://bugs.launchpad.net/neutron/+bug/1903531 - broken upgrade - we need fix it quickly or revert patch which broke it. 14:28:10 <openstack> Launchpad bug 1903531 in neutron "Update of neutron-server breaks compatibility to previous neutron-agent version" [Critical,Confirmed] 14:28:31 <slaweq> we broke compatibility between agents and server with that backport :/ 14:28:34 <slaweq> which is very bad 14:28:51 <slaweq> and we should now either fix that in stable branches or revert patch which caused that 14:29:06 <slaweq> any opinions which one is better? 14:29:30 <bcafarel> yup sorry I missed that "," in rpc change :/ 14:29:42 <ralonsoh> IMO, because we are changing the API content, we should revert the stable branch patches 14:29:44 <slaweq> bcafarel: yes, me too :/ 14:29:58 <bcafarel> as it is a security fix by itself additional fix would be great though 14:30:46 <slaweq> and the worst thing is that we merged that just before Stein EM, so we can't now do new Stein release, right? 14:31:07 <ralonsoh> I think so... 14:31:26 <bcafarel> transition patch is not merged yet hberaud had questions (lucky us) 14:31:43 <bcafarel> https://review.opendev.org/#/c/762404/ 14:31:54 <slaweq> ok, so lets revert it asap and do quickly one more release of stein 14:32:03 <slaweq> so this will be fixed in last released version 14:32:13 <slaweq> are You ok with that? 14:32:28 <ralonsoh> so, are we going to fix the fix or revert it for Stein? 14:32:35 <ralonsoh> I'm not sure 14:32:51 <slaweq> ralonsoh: I would go with revert in all stable branches 14:32:59 <slaweq> Train, Stein, Rocky and Queens 14:33:04 <ralonsoh> ok 14:33:18 <slaweq> good for You? 14:33:21 <ralonsoh> perfect 14:33:39 <slaweq> ok, I will propose backports immediatelly 14:34:45 <slaweq> reverts done for all stable branches 14:34:56 <slaweq> where it was backported 14:35:54 <slaweq> ok, good that someone found it before EM :) 14:36:04 <ralonsoh> sure 14:36:11 <slaweq> lets move on to the next one 14:36:14 <slaweq> https://bugs.launchpad.net/neutron/+bug/1903689 - stadium projects and neutron-lib issue 14:36:15 <openstack> Launchpad bug 1903689 in neutron "[stable/ussuri] Functional job fails - AttributeError: module 'neutron_lib.constants' has no attribute 'DEVICE_OWNER_DISTRIBUTED'" [Medium,New] 14:36:22 <slaweq> bcafarel You are on it, right? 14:36:38 <bcafarel> nice that we have the same list of bugs we wanted to talk about :) 14:36:51 <slaweq> :) 14:36:54 <bcafarel> slaweq: looking into it yes, not sure yet how to fix it 14:37:08 <bcafarel> it seems neutron is missing in u-c in ussuri and newer branches 14:38:31 <bcafarel> also, a semi-related bug here, the sibling system does not work with UT tests py38 (seen in https://review.opendev.org/#/c/743487 ) 14:38:58 <slaweq> bcafarel: You mean here https://github.com/openstack/requirements/blob/stable/victoria/upper-constraints.txt right? 14:39:02 <bcafarel> as that part is a bit voodoo/black magic to me, if some experts could check 14:39:29 <bcafarel> slaweq: yes, train and before had a "neutron==xx" line 14:39:42 <slaweq> yes, I see 14:42:47 <slaweq> bcafarel: I see that this py38 job is failing due to this issue with neutron version 14:42:48 <slaweq> no? 14:43:23 <bcafarel> yes error is same but py36/36 are working (siblings working correcly?) 14:43:24 <lajoskatona> bcafarel: it seems that this patch removed neutron from u-c file: https://review.opendev.org/553030 14:44:15 <bcafarel> lajoskatona looks like a good suspect! 14:44:23 <lajoskatona> no, it is from rocky perhaps, but not sure 14:44:48 <lajoskatona> but anyway, it seems that this happened in history :-) 14:45:39 <slaweq> but it is later in e.g. train 14:47:00 <slaweq> ok, bcafarel I hope You will take care of it 14:47:11 <slaweq> if You will need any help, please ping me 14:47:29 <bcafarel> will do! 14:47:34 <slaweq> thx 14:47:36 <slaweq> ok, lets move on 14:47:41 <slaweq> next is CI related bug 14:47:43 <slaweq> https://bugs.launchpad.net/neutron/+bug/1903985 14:47:45 <openstack> Launchpad bug 1903985 in neutron "[functional] Timeouts during setting link attributes in the namepaces" [High,Confirmed] 14:48:05 <slaweq> we see it more and more IMO recently 14:48:36 <slaweq> so we need someone who will maybe take a look at those logs and try to disable logging of some of errors in stdout/stderr 14:49:43 <slaweq> if anyone have any cycles, that would be great 14:49:50 <ralonsoh> this problem is specific to port.link.set_up() 14:50:03 <ralonsoh> I think that could be a problem with the device created 14:50:08 <slaweq> ahh, right ralonsoh 14:50:10 <slaweq> sorry 14:50:15 <slaweq> I was thinking about different issue 14:50:20 <slaweq> true 14:50:32 <slaweq> but this also happens from time to time recently :) 14:50:33 <ralonsoh> it uses privileged.set_link_attribute 14:50:35 <ralonsoh> sure 14:50:40 <ralonsoh> I'll check it today 14:50:47 <slaweq> thx 14:51:07 <slaweq> and the last one which I wanted to mention today is 14:51:10 <slaweq> https://bugs.launchpad.net/neutron/+bug/1904041 14:51:11 <openstack> Launchpad bug 1904041 in neutron "Victoria neutron-db-sync fails with I38991de2b4_source_and_destination_ip_prefix_neutron_metering_rule.py" [Undecided,New] 14:51:18 <slaweq> which is already initially checked by ralonsoh 14:51:21 <slaweq> thx for that 14:51:32 <ralonsoh> I can't reproduce this issue 14:51:38 <ralonsoh> even modifying the DB manually 14:51:43 <slaweq> it also works fine in our CI 14:51:54 <slaweq> on every run db migration script is run, right? 14:52:00 <ralonsoh> yes 14:52:34 <slaweq> ok, lets wait for some more informations and we will see 14:53:04 <slaweq> and that are all bugs which I wanted to raise here from lucasgomes' report 14:53:15 <slaweq> this week our bug deputy is jlibosva 14:53:24 <slaweq> I already contacted him to remind it 14:53:32 <slaweq> and next week is obondarev's turn 14:53:50 <slaweq> for next week I will prepare new round 14:54:15 <obondarev> + 14:54:19 * bcafarel gets ready 14:54:34 <slaweq> with that I'm done for today 14:54:44 <slaweq> do You have anything else You want to discuss with the team? 14:54:50 <ralonsoh> not from e 14:54:53 <ralonsoh> me* 14:55:18 <bcafarel> all good, both bugs I wanted to talk about were mentioned 14:55:25 <njohnston> I have one thing 14:55:34 <slaweq> njohnston: sure 14:55:49 <njohnston> with the work getting started with the Secure RBAC popup team, do we have to think about the impact for stadium projects at this point? 14:56:53 <slaweq> what is exactly Secure RBAC popup team? I think I missed something 14:57:11 <njohnston> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018800.html 14:57:59 <lajoskatona> it is mostly about testing, or am I wrong? 14:58:38 <slaweq> njohnston: thx for raising this up, I will read this email as I missed it earlier 14:58:52 <slaweq> and also I think we need amotoki to be involved in that 14:58:52 <njohnston> It is, but for some roles that don't correspond to roles we have in traditional policies we may find some gaps or bugs 14:59:40 <njohnston> +1 14:59:46 <amotoki> I just talked with gmann and am trying to catch up the discussion in the policy meeting 14:59:59 <slaweq> amotoki: great, thx 15:00:10 <amotoki> but we need to explore how we can cover policy testing in our repo 15:00:11 <slaweq> so lets get back to this on our next meeting 15:01:07 <slaweq> ok, we are out of time now 15:01:13 <mlavalle> o/ 15:01:15 <slaweq> thx for attending the meeting 15:01:17 <lajoskatona> o/ 15:01:18 <slaweq> o/ 15:01:19 <njohnston> o/ thanks 15:01:19 <ralonsoh> bye 15:01:20 <amotoki> o/ 15:01:20 <slaweq> #endmeeting