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