14:00:04 <slaweq> #startmeeting networking 14:00:05 <openstack> Meeting started Tue Aug 4 14:00:04 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:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:08 <openstack> The meeting name has been set to 'networking' 14:00:11 <slaweq> hi 14:01:00 <bcafarel> o/ 14:01:13 <amotoki> hi 14:01:19 <mlavalle> o/ 14:01:32 <lajoskatona> o/ 14:01:35 <rubasov> o/ 14:01:44 <ralonsoh> hi 14:01:56 <slaweq> ok, lets start 14:02:03 <slaweq> welcome everyone 14:02:13 <slaweq> #topic Announcements 14:02:33 <slaweq> release calendar updates: 14:02:38 <slaweq> We just reached Victoria-2 milestone, next one will be in the week of 7th September which is also Feature and Requirements freeze 14:03:02 <slaweq> so we should now focus on implementation of the BPs which are accepted and scheduled for this cycle 14:03:28 <slaweq> next one 14:03:43 <slaweq> Networking-midonet - my last call for maintainers email seems that was success 14:04:22 <slaweq> there is guy from the Netways company who wants to maintain it still 14:04:28 <amotoki> really good news 14:04:40 <slaweq> for now I pointed him to sync with yamamoto 14:04:52 <slaweq> but I will not start "deprecating" it this cycle 14:04:57 <slaweq> lets see how it will be 14:05:15 <amotoki> perhaps he needs to sync information including not only networking-midonet but also midonet with yamamoto 14:05:26 <slaweq> amotoki: yes, I think so 14:05:53 <slaweq> and I also told him that first step will be probably fix of the networking-midonet's gate jobs 14:05:58 <njohnston> o/ 14:05:58 <slaweq> which I can try to help 14:06:37 <bcafarel> yes that should be a good test :) 14:06:51 <slaweq> now I'm waiting for response from them 14:07:12 <slaweq> last announcement from me for today: 14:07:18 <slaweq> CFP deadline for virtual Open Infrastructure Summit is today: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016245.html 14:07:36 <slaweq> if You want to talk about something during this summit, please submit proposal ASAP :) 14:07:45 <slaweq> (and sorry that I missed that one last week) 14:08:13 <slaweq> any other announcements for today? 14:08:58 <bcafarel> just service announcement, if you have not hit it yet in your patches, gates are broken for train/ussuri/master http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016236.html 14:09:00 <bcafarel> in most projects 14:09:13 <radez> o/ sry was in the wrong meeting room :) 14:09:43 <slaweq> bcafarel: yes, thx for the heads up 14:10:07 <slaweq> so if Your patch failed on the lower-constraints job, please don't recheck yet - it will not help for sure 14:10:12 <slaweq> radez: welcome 14:10:31 <slaweq> btw. radez is our new squad member in RH and he is starting working on Neutron now 14:10:34 <slaweq> :) 14:10:35 <amotoki> bcafarel: it looks like pip behavior has been changed somehow.... pip seems to check requirement inconsistency but we need more detali check 14:10:47 <radez> Hello everyone 14:10:53 <ralonsoh> btw, now we have a problem with grenade jobs 14:10:57 <ralonsoh> just another heads-up 14:10:59 <bcafarel> :'( 14:11:26 <lajoskatona> ralonsoh: I've seen that, but personally I never debugged grenade.... 14:11:41 <bcafarel> ralonsoh: because we have lower-constraints issue also in stable branches, or another issue? 14:12:06 <ralonsoh> other issue 14:12:28 <ralonsoh> an example: https://026716e2072b41f3360b-f5b932bfaec6245f8b3ddc87df48d7a4.ssl.cf2.rackcdn.com/640258/23/check/neutron-grenade-multinode/bcc8e1e/job-output.txt 14:14:05 <slaweq> seems like some issue with OSC syntax: https://026716e2072b41f3360b-f5b932bfaec6245f8b3ddc87df48d7a4.ssl.cf2.rackcdn.com/640258/23/check/neutron-grenade-multinode/bcc8e1e/controller/logs/grenade.sh_log.txt ? 14:14:31 <slaweq> or with nova's _get_inventory_value function 14:14:55 <slaweq> ralonsoh: do You know if that is reported somewhere? 14:15:05 <slaweq> as it doesn't seems like neutron related problem 14:15:08 <ralonsoh> slaweq, no, I'm still investigating 14:15:12 <ralonsoh> I'll ping Nova folks 14:15:16 <amotoki> placement project provides OSC plugin 14:15:17 <slaweq> ralonsoh: thx 14:15:25 <ralonsoh> and I'll open a LP bug just to track it 14:15:35 <amotoki> I wonder something is changed.... 14:15:43 <tosky> I think they should see the same issue; have you checked their grenade jobs? 14:16:34 <ralonsoh> still checking 14:17:01 <amotoki> it looks like nova grenade job is failing for example https://review.opendev.org/#/c/743319/ 14:17:42 <ralonsoh> but not in current zuul jobs 14:18:15 <slaweq> but it seems for me that nova grenade jobs are failing on some other issue 14:18:17 <lajoskatona> I checked and the rp uuid is missing before the VCPU class name 14:18:41 <slaweq> ralonsoh: please open LP for that and we can discuss it later also 14:18:45 <ralonsoh> sure 14:18:51 <slaweq> and lets move on here with the agenda 14:19:15 <slaweq> #topic Blueprints 14:19:30 <slaweq> I updated list of our BPs for Victoria-3: https://launchpad.net/neutron/+milestone/victoria-3 14:19:41 <slaweq> do You have any updates about any of them? 14:21:03 <rubasov> I'm working on some tempest (or neutron-tempest-plugin) tests for metadata-ipv6 14:21:23 <slaweq> rubasov: thx, that would be great 14:21:48 <slaweq> I still need to review Your opened patches 14:21:59 <rubasov> thank you in advance 14:22:15 <slaweq> and others, please review them too: https://review.opendev.org/#/q/topic:metadata-ipv6+(status:open+OR+status:merged) 14:22:29 <rubasov> please note there's a small doc change in nova too 14:22:52 <rubasov> because that's where we have metadata end-user docs 14:23:25 <slaweq> rubasov: sure 14:23:27 <rubasov> that's all from me 14:23:39 <slaweq> it has the same topic so is in the list already 14:24:44 <slaweq> mlavalle: I have a question to You about https://blueprints.launchpad.net/neutron/+spec/dns-records-in-neutron 14:24:59 <slaweq> did You talk with hamza to check if we can mark it as done? 14:25:27 <mlavalle> slaweq: yes, we can 14:25:33 <slaweq> mlavalle: thx 14:25:38 <mlavalle> I think I mentioned it to you last week in the channel 14:25:58 <slaweq> You said that You will ask hamza if there is for sure nothing else todo there :) 14:27:23 <mlavalle> cool 14:27:41 <slaweq> I will try next week to focus on https://blueprints.launchpad.net/neutron/+spec/enginefacade-switch also as there is no a lot of patches to do 14:28:14 <slaweq> ralonsoh: I also have a question about https://bugs.launchpad.net/neutron/+bug/1888487 14:28:15 <openstack> Launchpad bug 1888487 in neutron "Change the default value of "propagate_uplink_status" to True" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) 14:28:15 * bcafarel remembers he said he would try to help there too... 14:28:32 <slaweq> is the neutron-lib patch which You send the only one needed? or some changes on neutron's side will be needed too? 14:28:40 <ralonsoh> both 14:28:48 <ralonsoh> let me write the changes 14:28:59 <ralonsoh> https://review.opendev.org/#/q/topic:bug/1888487+(status:open+OR+status:merged) 14:30:08 <slaweq> ralonsoh: ok, thx for the link 14:30:26 <slaweq> here it should be easy as both patches are small so easy to review :) 14:30:50 <slaweq> any other updates about BPs today? 14:30:53 <slaweq> or can we move on? 14:32:26 <slaweq> ok, so lets move on 14:32:32 <slaweq> #topic Community Goals 14:32:53 <slaweq> last week I made some progress with "Migrate CI/CD jobs to new Ubuntu LTS Focal" 14:33:12 <slaweq> I was debugging failures in our functional/fullstack jobs and I found that there were mostly 2 issues: 14:33:23 <slaweq> 1. missing ncat package on the test node, 14:33:52 <slaweq> 2. problem with ebtables-nft which is used by default and which don't supports filtering by IP address in arp filtering rules 14:34:06 <slaweq> for 1. I added installation of the ncat package simply and it is fine 14:34:26 <slaweq> for 2. I added playbook to switch to ebtables-legacy and that solved the issue for us 14:34:46 <slaweq> patches are https://review.opendev.org/#/c/734304/ and https://review.opendev.org/#/c/744500/ 14:35:14 <slaweq> neutron-tempest-dvr-ha-multinode-full job switch https://review.opendev.org/737370 looks ok - this job is passing 14:35:40 <slaweq> most of the other jobs should be switched by changes in the tempest jobs definition 14:35:57 <slaweq> I will sync with gmann about progress there 14:36:17 <slaweq> anything else You want to add regarding this Ubuntu Focal? 14:36:29 <bcafarel> yes when I had checked them they all just inherited from tempest or devstack nodeset 14:36:38 <bcafarel> so should switch by themselves 14:37:28 <bcafarel> in https://review.opendev.org/738163 dNM patch they should run with Focal 14:37:50 <bcafarel> also pep8 will need newer pylint (that supports python 3.8), https://review.opendev.org/#/c/744211/ 14:39:43 <slaweq> thx bcafarel for the updates 14:39:57 <slaweq> ok, lets move on quickly as we have few more items for today 14:40:14 <slaweq> regarding zuul v3 migration I don't have any updates today 14:40:24 <slaweq> and I don't think anyone made any progress with that 14:40:52 <slaweq> so, lets move on to the next topic 14:40:56 <slaweq> #topic Bugs 14:41:00 <slaweq> amotoki was bug deputy 14:41:05 <amotoki> I just sent my report just before the meeting. sorry for late. http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016290.html 14:41:17 <slaweq> amotoki: thx for the report 14:41:24 <amotoki> Most of them are about gate failures and OVN feature gaps. 14:41:28 <amotoki> Two bugs are not triaged. Both affects neutron behaviors and they are not simple bugs. They need more opinions. 14:41:55 <amotoki> bug 1889631 and bug 1889454 14:41:57 <openstack> bug 1889631 in neutron "[OVS][FW] Multicast non-IGMP traffic is allowed by default, not in iptables FW" [Undecided,New] https://launchpad.net/bugs/1889631 14:41:58 <openstack> bug 1889454 in neutron "br-int has an unpredictable MTU" [Undecided,New] https://launchpad.net/bugs/1889454 14:42:42 <slaweq> yes, bug 1889631 is also added by ralonsoh to the on demand topics 14:42:54 <ralonsoh> about this one, just the question is 14:43:02 <ralonsoh> should we block this traffic? by default 14:43:22 <ralonsoh> because that was the behaviour in iptables 14:43:31 <amotoki> from POV of migration from iptables FW, it should be blocked by default, 14:43:31 <ralonsoh> and we can't add a blocking rule in the FW 14:43:39 <amotoki> but we already have ovs-fw deployments. 14:43:44 <amotoki> that's the tricky point 14:43:47 <ralonsoh> agree 14:44:01 <ralonsoh> ok, one suggestion 14:44:13 <ralonsoh> this traffic is allowed by default, as I commented in the bug 14:44:23 <ralonsoh> according to https://tools.ietf.org/html/rfc4541 14:44:36 <ralonsoh> can we add a new knob in the config? 14:44:50 <ralonsoh> to explicitly block this traffic in OVS FW 14:45:17 <ralonsoh> (by default: current behaviour, not blocking) 14:45:25 <amotoki> but The config affects the API behavior. this is another tricky point.... 14:45:56 <ralonsoh> right: you can write a rule that will affect or not depending on the config 14:47:05 <ralonsoh> but giving the administrator the ability to enable/disable it, is enough at least from the compatibility point of view 14:47:09 <slaweq> my argument for blocking that traffic is that currently user can add rule to explicity allow such kind of traffic and it will work as expected with iptables_hybrid driver but will not work as expected with ovs fw driver 14:47:18 <ralonsoh> yes 14:47:26 <amotoki> one idea is to add a new rule during migration explicitly 14:47:28 <ralonsoh> but we can have native users 14:47:30 <slaweq> or even more, it will not work as expected when user will remove the rule 14:47:37 <ralonsoh> that have never used iptables before 14:47:48 <ralonsoh> now this traffic will be unexpectedly blocked 14:48:00 <slaweq> we can add upgrade check maybe: 14:48:30 <slaweq> or not, never mind 14:49:15 <ralonsoh> do you want to move this conversation to the LP? 14:49:42 <amotoki> I think it is better. 14:49:49 <ralonsoh> thanks! 14:50:06 <slaweq> ralonsoh: maybe You can also send email about that tot he ML? 14:50:12 <ralonsoh> I'll do it 14:50:15 <slaweq> thx 14:50:25 <amotoki> I also had two general questions during triaging bugs. 14:50:33 <amotoki> hte one is about l3-dvr-backlog tag 14:50:49 <amotoki> it was originally introduced to identify DVR feature gaps. 14:51:03 <amotoki> do we want some similar tag for OVN L3 feature gaps? 14:51:51 <amotoki> the other is how should we triage fwaas bugs? I haven't triaged a fwaas bug with neutron tempest plugin yet. 14:52:35 <amotoki> those are my questions 14:52:36 <slaweq> about ovn bugs, IMO "ovn" tag is enough 14:52:52 <amotoki> sounds fair 14:52:57 <slaweq> I'm not sure if we need any other tag for ovn related things 14:53:47 <slaweq> and speaking about the fwaas I think the only thing we can do is "best effort" triage as there is no fwaas team anymore 14:53:49 <bcafarel> so far just "ovn" went fine I think 14:54:17 <slaweq> I wouldn't treat those fwaas bugs as our top priority TBH 14:55:03 <amotoki> thanks. I already added 'fwaas' tag, so perhaps it would be enough. 14:55:11 <slaweq> ok 14:55:14 <slaweq> thx amotoki 14:55:49 <njohnston> yes I would rate any FWaaS bug as importance 'low' 14:55:58 <slaweq> regarding 1889454 - please read it and continue discussion in LP 14:57:09 <slaweq> ok, any other bugs You want to discuss today? 14:58:09 <slaweq> I will take this as "no" 14:58:14 <ralonsoh> no 14:58:20 <bcafarel> indeed 14:58:30 <slaweq> as we are running out of time today, we don't have time for "on demand" topics 14:58:36 <slaweq> so just quickly 14:59:18 <slaweq> mlavalle: I will check with amotoki and prepare new release of neutron-lib this week 14:59:34 <mlavalle> slaweq: thanks! 14:59:37 <slaweq> amotoki: ok if I will ping You tomorrow morning about it? 15:00:00 <amotoki> slaweq: sure. 15:00:03 <slaweq> thx 15:00:11 <slaweq> and one last thing for today 15:00:25 <slaweq> this week our bug deputy is mlavalle - I hope You saw my email mlavalle :) 15:00:34 <mlavalle> I did tahnks! 15:00:37 <slaweq> thx 15:00:37 <mlavalle> thanks! 15:00:49 <slaweq> ralonsoh: sorry that we didn't get to Your 2 topics this week 15:00:56 <ralonsoh> np at all 15:00:57 <slaweq> thx for attending the meeting 15:00:59 <ralonsoh> bye 15:01:01 <slaweq> have a great week 15:01:02 <slaweq> o/ 15:01:02 <lajoskatona> bye 15:01:02 <mlavalle> o/ 15:01:04 <amotoki> o/ 15:01:05 <slaweq> #endmeeting