Tuesday, 2021-06-29

opendevreviewliuyulong proposed openstack/neutron master: Refactor DHCP common config options  https://review.opendev.org/c/openstack/neutron/+/79828500:52
opendevreviewMerged openstack/neutron master: Copy existing IPv6 leases to generated lease file  https://review.opendev.org/c/openstack/neutron/+/76287402:14
opendevreviewAkihiro Motoki proposed openstack/neutron-vpnaas stable/stein: Call helper to convert bytes to str for Python3 in netns-wrapper  https://review.opendev.org/c/openstack/neutron-vpnaas/+/79833106:34
*** ChanServ sets mode: +o slaweq08:02
*** ChanServ sets mode: -o slaweq08:07
opendevreviewMerged openstack/neutron master: Add fullstack test case for OVS DHCP extension  https://review.opendev.org/c/openstack/neutron/+/77656808:37
slaweqralonsoh hi, can You use Your stable +2 power and check https://review.opendev.org/q/If6ef990baf039c556d7420962ac4c54608711f06 ?09:13
slaweqthx in advance :)09:13
ralonsohsure09:13
opendevreviewyangjianfeng proposed openstack/neutron-lib master: [WIP] Adds l3-ndp-proxy extension api definition  https://review.opendev.org/c/openstack/neutron-lib/+/74752309:26
opendevreviewMerged openstack/neutron-lib master: Add Neutron's functional job to the neutron-lib's CI  https://review.opendev.org/c/openstack/neutron-lib/+/79728109:31
slaweqlajoskatona ralonsoh can one of You approve https://review.opendev.org/c/openstack/neutron/+/796272 maybe?09:40
slaweqthx in advance09:40
slaweqor ralonsoh let me know if I should bump oslo_log version and update that constants there09:40
ralonsohslaweq, why do you need a new version of oslo_log?09:41
slaweqralonsoh as XENA constant is available in version which isn't in lower-constraints IIRC09:42
ralonsohah yes09:42
ralonsohslaweq, let me check where is this constant09:42
ralonsohslaweq, this is in oslo.log==4.5.009:44
slaweqyes09:45
slaweqdo You want me to update that patch quickly?09:45
ralonsoh(it's on the comment...)09:45
ralonsohno, no need09:45
slaweqand bump oslo_log in lower-constraints?09:45
slaweqok, thx09:45
ralonsoh(I'm a bit blurry today)09:45
slaweqafter match yesterday? :)09:46
ralonsohah yes, what a match09:46
lajoskatonaslaweq: rodolfo was quicker than me:-)09:49
slaweqlajoskatona thx to You also :)09:49
stephenfino/ We're seeing some issues in nova CI jobs since yesterday. Apparently the port binding feature is being reported as unavailable09:58
stephenfinSpecifically https://bugs.launchpad.net/nova/+bug/1933954 and https://bugs.launchpad.net/nova/+bug/193395809:58
opendevreviewyangjianfeng proposed openstack/neutron stable/train: Add extension unit tests for conntrack_helper plugin  https://review.opendev.org/c/openstack/neutron/+/77449209:59
stephenfinAs you can see in the logs in the second of those from lyarwood, neutron is reporting "Extension binding-extended not supported by any of loaded plugins"09:59
stephenfindoes this ring a bell?09:59
stephenfinslaweq: I have a suspicion that ^ might be related to your change https://review.opendev.org/c/openstack/neutron/+/79314110:04
slaweqstephenfin yeah, I'm checking it right now10:04
slaweqstephenfin yes, it seems we are missing binding-extended in the https://github.com/openstack/neutron/blob/master/neutron/common/ovn/extensions.py#L8510:08
slaweq:/10:08
stephenfinwell at least it's easy to fix :)10:09
stephenfincan that be fixed easily, or should we revert the broken change temporarily to unblock the nova gate?10:09
slaweqshould be easy to fix, give me 2 minutes and I will propose patch10:11
stephenfinty :)10:12
opendevreviewSlawek Kaplonski proposed openstack/neutron master: [OVN] Add binding-extended to the ML2_SUPPORTED_API_EXTENSIONS  https://review.opendev.org/c/openstack/neutron/+/79863410:12
slaweqstephenfin can You try with ^^ ?10:13
stephenfinslaweq: Sure, I'll watch https://review.opendev.org/c/openstack/nova/+/79863510:15
stephenfinassuming the depends on works10:15
slaweqyes, depends should work10:16
slaweqthx10:16
opendevreviewMerged openstack/neutron master: Refactor DHCP common config options  https://review.opendev.org/c/openstack/neutron/+/79828510:34
opendevreviewyangjianfeng proposed openstack/neutron stable/ussuri: Keepalived version check  https://review.opendev.org/c/openstack/neutron/+/79833511:06
opendevreviewyangjianfeng proposed openstack/neutron stable/ussuri: HA-non-DVR router don't need manually add static route  https://review.opendev.org/c/openstack/neutron/+/79287611:08
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_DELETE events  https://review.opendev.org/c/openstack/neutron/+/79700411:11
opendevreviewRodolfo Alonso proposed openstack/neutron master: Sanitize MAC addresses  https://review.opendev.org/c/openstack/neutron/+/78983111:27
*** tbhchman is now known as tbachman11:29
ralonsohslaweq, lajoskatona do you think we can merge https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/520251?11:40
slaweqralonsoh IMO yes11:41
ralonsohI didn't +W because there was a lot of discussion around how to test the OF rules11:42
slaweqyes, there was this (IMO ugly) loop but as Iwamoto explained why it was like that, I'm ok with it11:43
ralonsohperfect11:45
lajoskatonaralonsoh, slaweq: this should work with all backends (ovn, ovs, lb...) am I right?11:45
ralonsohlajoskatona, yes11:45
opendevreviewSlawek Kaplonski proposed openstack/neutron master: Add extra logs to the network update callback in L3 agent  https://review.opendev.org/c/openstack/neutron/+/79864811:49
slaweqralonsoh can You also check https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/796858 ?11:52
slaweqstephenfin binding-extended extension is now available in jobs in https://review.opendev.org/c/openstack/nova/+/798635 - I'm not sure if failure in nova-live-migrate job there is still related to neutron, IMO not, but would be great if You could check also :)11:57
opendevreviewMerged openstack/neutron stable/stein: Remove FIP agent's gw port when L3 agent is deleted  https://review.opendev.org/c/openstack/neutron/+/79780711:59
opendevreviewMerged openstack/neutron stable/queens: Remove FIP agent's gw port when L3 agent is deleted  https://review.opendev.org/c/openstack/neutron/+/79776212:19
*** elvira1 is now known as elvira13:25
slaweq#startmeeting networking14:00
opendevmeetMeeting started Tue Jun 29 14:00:04 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
opendevmeetThe meeting name has been set to 'networking'14:00
mlavalleo/14:00
gibi\o14:00
amotokihi14:00
obondarevhi14:00
slaweqhi14:00
lajoskatonao/14:00
slaweqlet's start14:02
slaweq#topic Announcements14:02
slaweqXena cycle calendar https://releases.openstack.org/xena/schedule.html14:02
slaweqXena-2 milesone is in few weeks - Jul 12th14:02
ralonsohhi14:02
manubhi14:02
slaweqwe are going well with specs - thanks for all reviews You did14:03
slaweqand we still have few of them opened so there is more work to do there :)14:03
rubasovhi14:03
mlavalleToday I'll review https://review.opendev.org/c/openstack/neutron-specs/+/78379114:03
ivc_o/14:03
slaweqthx mlavalle14:04
slaweqexcept that one, there is also https://review.opendev.org/c/openstack/neutron-specs/+/770540 opened14:04
mlavalleyeah, that would be the next one for me14:04
slaweqthx14:04
mlavallemost likely tomorrow14:05
slaweqok, next one14:05
slaweqDrivers team members are now ops in the neutron channel: https://review.opendev.org/c/openstack/project-config/+/79652114:05
slaweqjust a heads-up that some of You have now new "super powers" :)14:05
mlavalleso we can wreck it?14:05
ralonsohI was going to ask this14:05
slaweqmlavalle You can try :P14:05
mlavalleLOL14:06
slaweqbut remember - https://www.youtube.com/watch?v=kb4jEHmH_kU :D14:06
manub:)14:07
slaweqand that's all announcements from me for today14:07
slaweqdo You have anything else You want to share with the team now?14:07
slaweqif not I think we can move on14:09
slaweq#topic Blueprints14:09
slaweqNeutron Xena-2 https://bugs.launchpad.net/neutron/+milestone/xena-214:09
slaweqI marked as implemented https://blueprints.launchpad.net/neutron/+spec/distributed-dhcp-for-ml2-ovs and https://blueprints.launchpad.net/neutron/+spec/default-dns-zone-per-tenant14:10
slaweqas all related patches are now merged14:10
slaweqfor https://blueprints.launchpad.net/neutron/+spec/bfd-support-for-neutron and https://blueprints.launchpad.net/neutron/+spec/explicit-management-of-default-routes we have already merged specs14:11
mlavalleNice!14:11
slaweqohh, so there is one more "prio" spec to review: https://review.opendev.org/c/openstack/neutron-specs/+/77951114:12
slaweqit's related to https://blueprints.launchpad.net/neutron/+spec/multiple-external-gateways14:12
mlavalleadded to my pile of this week. Coukld you please add it to the high priority reviews dashboard?14:13
mlavallethat way I don't forget14:13
slaweqmlavalle I just did14:13
slaweqthank You14:13
mlavalleThanks!14:13
rubasovmlavalle, slaweq: thanks14:13
slaweqand that are all updates from me regarding Blueprints14:13
slaweqany other updates regarding Blueprints?14:13
obondarevNode Local IP spec is published: https://review.opendev.org/c/openstack/neutron-specs/+/79779814:13
obondarevearly comments are welcome :)14:13
mlavalledo you want to implement it this cycle?14:14
obondarevI guess start this cycle14:14
obondarevY is more realistic14:15
mlavalleahh, ok. Just to have an idea of priorities14:15
mlavalleI'll look at it soon, anyways14:15
slaweqobondarev ok, thx14:15
obondarevthanks14:15
slaweqso I set it to "neutron next" to not forget :)14:15
slaweqif there are no other updates, I think we can move on to the next topic14:17
slaweq#topic Bugs14:18
slaweqamotoki was bug deputy last week14:18
* mlavalle likes amotoki's bug report format14:18
amotokimy report is found at http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023362.html  sorry for late14:18
amotokithere are three bugs which need attentions: one OVN related and two DVR related.14:19
amotokiI haven't succeeded to repro the OVN one related to security group rule operation14:20
amotokimlavalle: thanks14:20
slaweqI will take a look at the OVN one14:20
ralonsohme neither, I don't know what is failing there14:20
haleybslaweq: i was going to add a comment to the OVN one as it affects octavia, not sure how to address it14:21
slaweqRegarding https://bugs.launchpad.net/neutron/+bug/1933234 I today took a look. I have some initial toughts what is wrong there but I will need more logs in the L3 agent to confirm that14:22
slaweqhaleyb sure, feel free to take it if You want or update with Your ideas. I will take a look at it too, maybe I will find something there :)14:22
haleybslaweq: ack, i'll ping you after meeting since we need to work around it in Octavia14:23
amotokiregarding ONV one, 409 conflict will be retuned when an exception happens during BEFORE_DELETE hook.14:24
amotokiI am not sure we may want to control an exception more granually or it is just a bug in ovn driver.14:24
haleybamotoki: the rule might not exist, so returning a 409 seems wrong.  But i'm not sure we can change to SecurityGroupRuleNotFound without breaking something ?14:26
haleybwithout any callback registered it would return SecurityGroupRuleNotFound14:26
haleybi.e. without OVN14:26
amotokihaleyb: yeah, I am not sure what is wrong. it happens in BEFORE_DELETE so I wonder why not found is raised....14:27
opendevreviewIlya Chukhnakov proposed openstack/neutron-specs master: [WIP] Add Node-Local Virtual IP Spec  https://review.opendev.org/c/openstack/neutron-specs/+/79779814:27
haleybamotoki: the _registry_notify() call specifies SecurityGroupRuleInUse, which i'm assuming is the default when it fails?14:28
haleybthe callee can't say why it failed14:28
amotokihaleyb: yes, my understanding is same, but the error message from OVN driver says the rule is not found. that confuses me.14:29
haleyba few lines down it calls "sgr = self._get_security_group_rule(context, id)" which would also have returned Not Found, right?14:29
slaweqamotoki maybe it wasn't found in ovn db?14:29
amotokislaweq: it might be.14:29
amotokiit may happen14:30
haleybslaweq: i wonder if it's in the neutron DB?  would be easy enough to verifiy with two calls14:30
haleybthe bug report says there were multiple calls to remove the same rule14:30
slaweqhaleyb is it failing everytime in Octavia CI?14:30
slaweqor sometimes only?14:30
haleybgthiemonge would know14:30
amotokiI wonder it happens in a race condition.14:31
gthiemongehi14:31
haleybgthiemonge: talking about the SG issue with OVN14:31
amotokigthiemonge: we are talking about https://bugs.launchpad.net/bugs/1933638 you filed.14:31
haleyband i saw https://review.opendev.org/c/openstack/octavia/+/798676 to try and work around it14:32
gthiemongeso, it happened many times in CI, I didn't reproduce it in my env14:32
gthiemongeIn CI, we are deleting 2 or 3 times the same SG rule, the first one is ok, the 2nd one gets a 409 and sometimes there's 3rd one that gets a 40414:33
amotokithanks, so a race condition seems to happen.14:34
slaweqyes14:34
haleyboh, so it's not always a 409 on second and greater14:34
slaweqand 409 is definitely wrong as response to DELETE request14:34
amotokislaweq: totally agree14:34
ralonsohfolks, if the SG rule does not exist, the BEFORE_DELETE will raise always this exception in OVN14:35
ralonsohjust reading the code14:35
haleybralonsoh: that's what it looks like to me too14:35
ralonsohso we need to "hide" this exception in the event14:36
amotokiperhaps we can improve the notification logic so that we can control an exception raised.14:36
ralonsohand let the DB transaction to fail correctly14:36
amotoki+114:36
ralonsoh(1 bug less)14:36
gthiemongegthiemonge: I have this log file: https://9d5339e09bfaa3ab0b67-c3fbbb652718002c010964532c238f5b.ssl.cf5.rackcdn.com/798676/1/check/octavia-v2-dsvm-scenario/de9eccb/controller/logs/screen-q-svc.txt14:37
gthiemongestarting at 12:36:00.22696914:37
slaweqralonsoh do You want to send patch for that?14:37
gthiemonge3 DELETEs, response codes: 204, 404, 40914:37
ralonsohsure, right now14:37
slaweq++14:37
slaweqthank You14:37
gthiemongeralonsoh: thanks ;-)14:38
haleybralonsoh: yes, catching that and just returning might help, but it's odd we get multiple responses, anyways probably time to move on14:38
slaweqralonsoh assigned that bug to You14:38
slaweqok, thx amotoki for great summary of the bug deputy week14:40
amotokione last thing I would like to raise is https://bugs.launchpad.net/bugs/1930866  It was filed as a normal bug but it leads to an API change to handle this, so I marked it as RFE. feel free to share you thoughts.14:40
slaweqany other bugs to discuss today?14:40
amotokiwe don't need to discuss it here though.14:40
amotokithat's all from me.14:41
slaweqthx amotoki14:41
slaweqregarding that RFE I will check it later this week14:41
slaweqbut from quick look I think we discussed something like that with Nova team on one of the PTGs already14:42
slaweqok, so we should have something like "locked" port and then forbid to delete it probably14:43
slaweqI will check it and we will discuss it in the drivers meeting later14:43
slaweqso I think we can move on if there are no other bugs to discuss14:44
slaweqmlavalle is our bug deputy this week14:44
mlavalleo/14:44
slaweqand next week will be rubasov's turn14:44
rubasovack14:44
slaweqthx14:45
* mlavalle would appreciate if ralonsoh takes another look at https://bugs.launchpad.net/neutron/+bug/1933813. Submitter added some more info14:45
ralonsohmlavalle, sure14:45
slaweqok, so last topic for today14:45
slaweq#topic On Demand Agenda14:45
slaweqralonsoh You added topic there14:45
slaweqso all channel is Yours :)14:45
ralonsohsorry, link?14:46
ralonsohto the agenda14:46
slaweq(ralonsoh): https://bugs.launchpad.net/neutron/+bug/1933517. Proposed solution: https://bugs.launchpad.net/neutron/+bug/1933517/comments/114:46
slaweqhttps://wiki.openstack.org/wiki/Network/Meetings14:46
ralonsohahhh yes, sorry14:46
ralonsohwe have a serious problem with OVN live migrations14:46
ralonsohin OVS with hybrid plug we are ok14:46
ralonsohbecause os-vif creates a bridge between the VM and OVS14:46
ralonsohso Neutron is aware of this new port and creates the needed rules14:47
ralonsohwhen the VM is unpaused, the backend (OVS) is ready14:47
ralonsohin OVN and OVS native, this is not happening14:47
ralonsohbecause libvirt creates the port when the VM is unpaused14:47
ralonsohwhat Sean Mooney is proposing is something similar to OVS hhybird14:48
ralonsohbut with OVS bridges, created and deleted by os-vif14:48
ralonsoh1) this is 100% compatible with DPDK14:48
ralonsoh2) that won't affect performance: the bridge will collapse in the dataplane14:48
ralonsohof course, we'll have one extra bridge per VM port14:49
ralonsohso, this is is, in  a nuthsell, the problem and the proposed solution14:49
ralonsohdo you need a spec? a BP?14:49
ralonsohor this is a no-go feature14:49
ralonsoh(btw, in os-vif we don't differenciate OVS native or OVN ports, that will be applicable to OVS too)14:50
ralonsohand will be configurable14:50
ralonsohthat's all, feedback welcome 14:50
slaweqIMO it's "go" feature for sure as it will solve valid issue14:50
slaweqwhat are the cons of it?14:51
amotokia spec sounds reasonable to me as we need to capture the issue and understand the solution correctly. it also helps users understand the change.14:51
ralonsohamotoki, perfect14:51
mlavalleyeah, let's follow the RFE/spec process14:51
ralonsohcons: more bridges in OVS14:51
ralonsohmlavalle, I'll propose it14:51
mlavallethat way we can thoroughly discuss it14:51
amotokiI am not sure how the number of OVS bridges affects the performance. too many bridge works?14:52
rubasovmaybe it could be converged to how trunk ports have an extra bridge14:52
rubasovand then we would kill a few limitations of converting between normal and trunk ports14:52
ralonsohthis is not planning using linux bridges, but OVS ones14:52
ralonsohI wouldn't mix features14:53
ralonsohand the goal is to make neutron agnostic to this (with some exceptions related to QoS)14:53
ralonsohdo everything in os-vif14:53
ralonsohanyway, I'llpresent a spec14:53
slaweq++ for spec14:54
amotokiso do we convert https://bugs.launchpad.net/neutron/+bug/1933517 into RFE?14:54
ralonsohyes, should be a RFE14:55
slaweqstrictly speaking it should be like that IMO14:55
amotoki:)14:55
amotokiI added rfe-triaged tag to it14:56
slaweqthx amotoki14:56
slaweqwe are almost on top of the hour now14:57
slaweqand I think we can finish it now14:57
ralonsohbye14:57
slaweqthx for attending the meeting today14:57
slaweqo/14:57
rubasovo/14:57
slaweq#endmeeting14:57
opendevmeetMeeting ended Tue Jun 29 14:57:46 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:57
opendevmeetMinutes:        https://meetings.opendev.org/meetings/networking/2021/networking.2021-06-29-14.00.html14:57
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/networking/2021/networking.2021-06-29-14.00.txt14:57
opendevmeetLog:            https://meetings.opendev.org/meetings/networking/2021/networking.2021-06-29-14.00.log.html14:57
ivc_\o14:57
amotokio/14:57
lajoskatonao/14:57
slaweq#startmeeting neutron_ci15:00
opendevmeetMeeting started Tue Jun 29 15:00:06 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'neutron_ci'15:00
ralonsohhi15:00
slaweqhi again :)15:00
obondarevhi15:00
slaweqFirst of all Grafana dashboard: http://grafana.openstack.org/dashboard/db/neutron-failure-rate15:00
slaweqok, let's start15:01
slaweq#topic Actions from previous meetings15:01
slaweqslaweq to check failing update mtu fullstack test: https://bugs.launchpad.net/neutron/+bug/193323415:01
slaweqI checked it today15:01
slaweqand I think I know what is going on there, I described it in comment on LP: https://bugs.launchpad.net/neutron/+bug/1933234/comments/215:02
slaweqbut to confirm that I will need additional logs in L3 agent: https://review.opendev.org/c/openstack/neutron/+/79864815:02
opendevreviewIlya Chukhnakov proposed openstack/neutron-specs master: [WIP] Add Node-Local Virtual IP Spec  https://review.opendev.org/c/openstack/neutron-specs/+/79779815:02
lajoskatonaHi15:03
slaweqobondarev regarding Your question, I don't think it will be useful in that specific case to log those ports ids there but I can add it15:03
opendevreviewIlya Chukhnakov proposed openstack/neutron-specs master: [WIP] Add Node-Local Virtual IP Spec  https://review.opendev.org/c/openstack/neutron-specs/+/79779815:03
obondarevslaweq: got it15:04
slaweqand that's basically all regarding this issue for now15:06
opendevreviewMamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_DELETE events  https://review.opendev.org/c/openstack/neutron/+/79700415:06
slaweqif it will happen often I will propose to mark this test as unstable for now15:06
slaweqbut maybe it will not be necessary :)15:06
slaweqI think we can move on15:06
slaweqnext was:15:06
slaweqlajoskatona to check with infra status of the tap-as-a-service move15:06
opendevreviewMerged openstack/neutron-tempest-plugin master: Add a test for overlapping SG rules  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/52025115:08
opendevreviewMerged openstack/neutron-tempest-plugin master: Revert "Skip scenario tests if HA router will not be active"  https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/79685815:08
slaweqlajoskatona are You here?15:08
opendevreviewMerged openstack/neutron stable/ussuri: Updates for python3.8  https://review.opendev.org/c/openstack/neutron/+/79341715:08
lajoskatonasorry, yes15:09
lajoskatonaI asked around ( https://meetings.opendev.org/irclogs/%23openstack-infra/%23openstack-infra.2021-06-24.log.html#t2021-06-24T16:58:18 )15:10
lajoskatonasorry, my client plays with me15:10
lajoskatonaso basically whenever the move/rename happens all open patches will be moved15:11
slaweqso IIUC we are good to merge and send patches as we want now and we are good, right?15:12
lajoskatonaexactly15:12
slaweqgreat, thx lajoskatona :)15:12
slaweqok, that's all actions from previous meeting15:13
slaweq#topic Stadium projects15:13
slaweqlajoskatona any other updated about stadium's CI?15:13
lajoskatonathe only one is from the mail  http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023321.html to fix broken zuul config15:14
lajoskatonathat is mostly odl rocky perhaps, amotoki started to check that, thanks for that15:15
amotokiall jobs are failing. perhaps we can drop them15:15
slaweqI saw amotoki volunteered for that on ML so I didn't check it15:15
lajoskatonahttps://review.opendev.org/c/openstack/networking-odl/+/79829815:15
amotokibut requirements change is also required and the requirmenets-check fails too. I need to ask it to the requirments team.15:15
slaweqmaybe we should simply make networking-odl rocky EOL now?15:17
slaweqwdyt?15:17
lajoskatonaelod this morning mentioned something that isort is not in rocky requirements, and that one is broken too, so hard15:17
lajoskatonayeah, for ODL we seem to have even liberty (frm http://lists.openstack.org/pipermail/openstack-discuss/2021-June/023347.html & http://paste.openstack.org/show/806995/ )15:18
amotokilajoskatona: yes. we don't have a proper isort in the requirements, so if we'd like to fix it we also need a requirement change but the job is failing (it is not specific to neutron team)15:18
lajoskatonaamotoki: exactly15:19
lajoskatonaamotoki: so perhaps we can clean these old branches, not sure what to need for that15:19
amotokiI am okay with EOL'ing networking-odl rocky and older15:20
slaweqme too :)15:21
amotokilajoskatona: what do you mean by 'clean'? EOL?15:21
slaweqdo You want me to start that process?15:21
lajoskatonayes15:21
slaweqor do You want to do it?15:21
lajoskatonabut that means we put tag on it and the branch is deleted, or am I wrong?15:21
amotokislaweq: me?15:21
lajoskatonaI can15:21
amotokii can help it15:22
lajoskatonaamotoki: thanks15:22
amotokiI think we can drop jobs which cause zuul configuration error first along with failing jobs.15:22
amotokiin parallel, we can move forward the process of EOL of networking-eol older branches.15:23
lajoskatonaamotoki: ok15:23
slaweqsounds good for me15:23
slaweqso amotoki will You propose removal of that broken jobs?15:23
amotokislaweq: yes15:24
slaweqand lajoskatona You will start EOLing it, correct?15:24
lajoskatonasalweq: yes15:24
amotokiI will also check zuul errors in other repos this week.15:24
slaweq#action amotoki to clean failing jobs in networking-odl rocky and older15:24
slaweq#action lajoskatona to start EOL process for networking-odl rocky and older15:25
slaweqthank You both :)15:25
slaweqanything else or can we move on?15:26
lajoskatonayes15:27
slaweqlajoskatona "yes, something else" or "yes, we can move on"? :D15:27
amotokinone from me either15:27
lajoskatonasorry we can move15:28
slaweqok :)15:28
slaweqAs we don't have bcafarel today, I think we can skip stable branches topic15:28
slaweqI didn't saw any serious issues there last week15:28
slaweq#topic Grafana15:28
slaweqhttps://grafana.opendev.org/d/BmiopeEMz/neutron-failure-rate?orgId=115:29
slaweqI see that today neutron-tempest-slow-py3 is going high but there was small number of the runs so maybe it's nothing really serious15:31
slaweqworth to keep an eye on it for now15:31
slaweqother than that things looks pretty ok15:31
slaweqdo You see any issues there?15:32
slaweqok, so let's move on15:33
slaweq#topic fullstack/functional15:33
slaweqI noticed (again) functional tests failure with db migration timeouts this week:15:34
slaweqhttps://099638a2437d4a88b01b-b7b49a3857e4a968cf2542b58172db3c.ssl.cf2.rackcdn.com/798156/1/check/neutron-functional-with-uwsgi/6d49cc5/testr_results.html15:34
slaweqralonsoh may be interesting for You :)15:34
ralonsohI saw it, yes15:34
slaweqas I think You recently removed some skip if timeout decorator from those tests, right?15:34
ralonsohI'll keep an eye on the CI15:34
slaweqthx15:34
ralonsohsome weeks ago15:35
slaweqfor now I saw it only once so maybe nothing really serious and just very overloaded node15:35
ralonsohand we don't execute those test in parallel15:35
slaweqbut worth to be aware15:35
ralonsohagree15:35
slaweqand that's all regarding functional tests15:35
slaweqfor fullstack I only saw this error with mtu update15:35
slaweqbut that is already reported and in progress15:36
slaweqso I think we can move on15:36
slaweq#topic Tempest/Scenario15:36
slaweqneutron-tempest-slow-py3 - again nameservers issue15:36
slaweqhttps://8a9b6f5914f633048b01-596b3ee18079cc72e9aa5b1ed231f9fc.ssl.cf5.rackcdn.com/795117/12/check/neutron-tempest-slow-py3/6518f8d/testr_results.html15:36
ralonsohagain?15:36
slaweqralonsoh is Your fix related to such issue fixed already?15:36
ralonsohlet me check, I think so15:36
ralonsohI'll ping you later15:37
slaweqralonsoh yes, that was from yesterday so fresh thing :)15:37
slaweqok, please let me know if we should reopen our bug for that15:37
slaweqcan be tomorrow15:37
ralonsohah ok15:37
ralonsohbut we use cirros there, right?15:38
ralonsohmy patch introduced the use of resolvectl15:38
lajoskatonanot ubuntu?15:38
ralonsohthat is not in cirros, only advance images15:38
ralonsohyes, it's in ubuntu15:38
slaweqin this test we use cirros15:39
slaweqthis is tempest test15:39
slaweqnot neutron_tempest_plugin15:39
ralonsohyeah...15:39
lajoskatonaoh ,and there we use only cirros....15:39
ralonsohI think this is just a problem with the OS15:39
slaweqand in tempest there is no this "advanced image" thing15:39
slaweqit's only in neutron-tempest-plugin15:39
ralonsohyes... now I realized that15:39
ralonsohI'll see if, in cirros, there is another way to check that15:40
slaweqthx15:40
lajoskatonaand the reason behind using only cirros is to keep it tempest fast?15:41
slaweqralonsoh to check if there is better way to check dns nameservers in cirros15:41
slaweq#action ralonsoh to check if there is better way to check dns nameservers in cirros15:41
slaweqlajoskatona yes, with ubuntu and without nested virt it's a nightmare15:41
slaweqwe had it like that in neutron_tempest_plugin jobs in the past15:41
slaweqand that's why we did this advanced_image option to use ubuntu only for some tests15:41
slaweqnot for all15:41
lajoskatonaok, thanks15:42
slaweqok, that's basically all what I had for today for You15:43
slaweqgenerally CI looks pretty ok, I see many patches merged without rechecks recently15:43
slaweqgreat job guys with all those CI issues :)15:43
slaweqthank You!15:43
slaweqdo You have anything else what You would like to discuss today?15:44
slaweqor if not, we can finish a bit earlier today15:44
ralonsohI'm fine15:45
lajoskatoname too15:46
slaweqok, thx for attending the meeting15:46
ralonsohbye15:46
slaweqand have a great week15:46
slaweqo/15:46
slaweq#endmeeting15:46
opendevmeetMeeting ended Tue Jun 29 15:46:21 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:46
opendevmeetMinutes:        https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-06-29-15.00.html15:46
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-06-29-15.00.txt15:46
opendevmeetLog:            https://meetings.opendev.org/meetings/neutron_ci/2021/neutron_ci.2021-06-29-15.00.log.html15:46
amotokio/15:46
lajoskatonao/15:46
opendevreviewSlawek Kaplonski proposed openstack/neutron-specs master: Neutron VLAN networks with QinQ enabled  https://review.opendev.org/c/openstack/neutron-specs/+/79870415:48
opendevreviewRodolfo Alonso proposed openstack/neutron master: [OVN] Do not fail when processing SG rule deletion  https://review.opendev.org/c/openstack/neutron/+/79871817:00
opendevreviewBrian Haley proposed openstack/ovn-octavia-provider master: Add Health Monitor support  https://review.opendev.org/c/openstack/ovn-octavia-provider/+/71325320:35
opendevreviewVadim Ponomarev proposed openstack/neutron-lib master: Introduce rbac-bgpvpn api extension  https://review.opendev.org/c/openstack/neutron-lib/+/79542321:31
*** ChanServ sets mode: +o slaweq21:34
*** ChanServ sets mode: -o slaweq21:36
opendevreviewMerged openstack/networking-ovn stable/train: [OVN] Disable mcast_flood on localnet ports  https://review.opendev.org/c/openstack/networking-ovn/+/79781722:51

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!