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