Wednesday, 2020-07-01

*** yasufum has joined #openstack-meeting00:04
*** yasufum_ has joined #openstack-meeting00:06
*** yasufum has quit IRC00:08
*** yasufum_ is now known as yasufum00:08
*** diurnalist has quit IRC00:13
*** jmasud has quit IRC00:17
*** jmasud has joined #openstack-meeting00:20
*** andrebeltrami has quit IRC00:38
*** yamamoto has joined #openstack-meeting00:46
*** jmasud has quit IRC00:48
*** yamamoto has quit IRC00:49
*** yamamoto has joined #openstack-meeting00:58
*** diurnalist has joined #openstack-meeting01:08
*** Liang__ has joined #openstack-meeting01:17
*** markvoelker has joined #openstack-meeting01:20
*** markvoelker has quit IRC01:24
*** jmasud has joined #openstack-meeting01:32
*** gyee has quit IRC01:35
*** yaawang has quit IRC01:42
*** ricolin_ has joined #openstack-meeting01:43
*** yaawang has joined #openstack-meeting01:43
*** Liang__ has quit IRC01:46
*** diurnalist has quit IRC02:07
*** hyunsikyang has joined #openstack-meeting02:18
*** jmasud has quit IRC02:45
*** yaawang has quit IRC02:45
*** yaawang has joined #openstack-meeting02:46
*** yasufum has quit IRC02:50
*** jmasud has joined #openstack-meeting02:53
*** yasufum has joined #openstack-meeting02:59
*** yasufum has quit IRC03:13
*** armax has quit IRC03:19
*** rfolco has quit IRC03:20
*** ricolin_ is now known as ricolin03:30
*** psachin has joined #openstack-meeting03:33
*** Liang__ has joined #openstack-meeting03:58
*** markvoelker has joined #openstack-meeting04:03
*** diurnalist has joined #openstack-meeting04:05
*** yasufum has joined #openstack-meeting04:05
*** markvoelker has quit IRC04:08
*** yasufum has quit IRC04:14
*** Lucas_Gray has quit IRC04:30
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-meeting04:33
*** apetrich has quit IRC04:43
*** moguimar has joined #openstack-meeting04:44
*** mugsie has quit IRC04:53
*** mugsie has joined #openstack-meeting04:57
*** markvoelker has joined #openstack-meeting05:03
*** strigazi has quit IRC05:04
*** diurnalist has quit IRC05:06
*** strigazi has joined #openstack-meeting05:06
*** markvoelker has quit IRC05:07
*** psahoo has joined #openstack-meeting05:21
*** vishalmanchanda has joined #openstack-meeting05:23
*** links has joined #openstack-meeting05:34
*** yaawang has quit IRC05:45
*** yaawang has joined #openstack-meeting05:45
*** strigazi has quit IRC05:46
*** njohnston has quit IRC06:18
*** yasufum has joined #openstack-meeting06:26
*** tetsuro has joined #openstack-meeting06:33
*** tetsuro has quit IRC06:43
*** tetsuro has joined #openstack-meeting06:43
*** tetsuro has quit IRC06:43
*** yaawang has quit IRC06:43
*** yaawang has joined #openstack-meeting06:51
*** tetsuro has joined #openstack-meeting06:55
*** yaawang has quit IRC06:55
*** yaawang has joined #openstack-meeting06:55
*** tetsuro has quit IRC06:56
*** psahoo has quit IRC07:00
*** psahoo has joined #openstack-meeting07:00
*** rcernin has quit IRC07:02
*** markvoelker has joined #openstack-meeting07:04
*** rcernin has joined #openstack-meeting07:05
*** markvoelker has quit IRC07:09
*** slaweq has quit IRC07:12
*** slaweq has joined #openstack-meeting07:13
*** markvoelker has joined #openstack-meeting07:18
*** markvoelker has quit IRC07:23
*** rcernin has quit IRC07:30
*** Liang__ has quit IRC07:30
*** Liang__ has joined #openstack-meeting07:31
*** ralonsoh has joined #openstack-meeting07:33
*** ociuhandu has quit IRC07:41
*** yasufum has quit IRC07:48
*** rcernin has joined #openstack-meeting07:50
*** ttsiouts has joined #openstack-meeting07:53
*** ttsiouts has quit IRC07:53
*** ttsiouts has joined #openstack-meeting07:54
*** e0ne has joined #openstack-meeting07:58
*** rcernin has quit IRC08:06
*** ociuhandu has joined #openstack-meeting08:20
*** ttsiouts has quit IRC08:37
*** ttsiouts has joined #openstack-meeting08:38
*** yasufum has joined #openstack-meeting08:39
*** ttsiouts has quit IRC08:42
*** yaawang has quit IRC08:46
*** yaawang has joined #openstack-meeting08:46
*** apetrich has joined #openstack-meeting08:48
*** yasufum has quit IRC08:51
*** yasufum has joined #openstack-meeting08:56
*** ttsiouts has joined #openstack-meeting09:27
*** yaawang has quit IRC09:30
*** yaawang has joined #openstack-meeting09:31
*** Lucas_Gray has joined #openstack-meeting09:33
*** yamamoto has quit IRC09:37
*** moguimar has quit IRC09:41
*** moguimar has joined #openstack-meeting09:41
*** yasufum has quit IRC09:42
*** ricolin has quit IRC09:52
*** yamamoto has joined #openstack-meeting09:55
*** yamamoto has quit IRC10:06
*** yamamoto has joined #openstack-meeting10:07
*** apetrich has quit IRC10:12
*** moguimar has quit IRC10:17
*** moguimar has joined #openstack-meeting10:17
*** moguimar has quit IRC10:19
*** moguimar has joined #openstack-meeting10:19
*** moguimar has joined #openstack-meeting10:20
*** Liang__ has quit IRC10:40
*** janders has joined #openstack-meeting10:52
*** njohnston has joined #openstack-meeting11:01
*** priteau has joined #openstack-meeting11:02
*** janders has quit IRC11:03
*** rajivmucheli has joined #openstack-meeting11:04
*** verdurin has joined #openstack-meeting11:04
*** janders has joined #openstack-meeting11:05
*** kevinz has quit IRC11:11
*** markvoelker has joined #openstack-meeting11:15
*** ykatabam has quit IRC11:15
*** ykatabam has joined #openstack-meeting11:16
*** markvoelker has quit IRC11:19
*** raildo has joined #openstack-meeting11:28
*** janders has quit IRC11:30
*** apetrich has joined #openstack-meeting11:45
*** rh-jelabarre has joined #openstack-meeting11:50
*** csatari has quit IRC11:53
*** csatari has joined #openstack-meeting11:56
*** Lucas_Gray has quit IRC11:58
*** rajivmucheli has quit IRC11:59
*** Lucas_Gray has joined #openstack-meeting12:00
*** rajivmucheli has joined #openstack-meeting12:01
*** andrebeltrami has joined #openstack-meeting12:06
*** alecuyer has quit IRC12:12
*** psahoo_ has joined #openstack-meeting12:12
*** psahoo has quit IRC12:16
*** irclogbot_1 has quit IRC12:16
*** irclogbot_3 has joined #openstack-meeting12:17
*** JangwonLee_ has joined #openstack-meeting12:31
*** rajivmucheli has quit IRC12:35
*** trident has quit IRC12:46
*** trident has joined #openstack-meeting12:49
*** ricolin has joined #openstack-meeting12:54
*** rfolco has joined #openstack-meeting13:00
*** manuvakery has joined #openstack-meeting13:03
*** yasufum has joined #openstack-meeting13:10
*** yasufum has quit IRC13:14
*** yasufum has joined #openstack-meeting13:15
*** abhishekk has quit IRC13:22
*** jhesketh has quit IRC13:22
*** abhishekk has joined #openstack-meeting13:23
*** jhesketh has joined #openstack-meeting13:24
*** Lucas_Gray has quit IRC13:27
*** Lucas_Gray has joined #openstack-meeting13:30
*** psachin has quit IRC13:31
*** TrevorV has joined #openstack-meeting13:31
*** yasufum has quit IRC13:32
*** dklyle has quit IRC13:35
*** rajivmucheli has joined #openstack-meeting13:44
*** liuyulong has joined #openstack-meeting13:50
*** yamamoto has quit IRC13:50
*** yasufum has joined #openstack-meeting13:53
*** mlavalle has joined #openstack-meeting13:58
liuyulong#startmeeting neutron_l314:02
openstackMeeting started Wed Jul  1 14:02:54 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.14:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:02
*** openstack changes topic to " (Meeting topic: neutron_l3)"14:02
openstackThe meeting name has been set to 'neutron_l3'14:02
*** Liang__ has joined #openstack-meeting14:02
*** Liang__ is now known as LiangFang14:02
liuyulong#topic Announcements14:03
*** openstack changes topic to "Announcements (Meeting topic: neutron_l3)"14:03
slaweqhi14:03
liuyulonghi14:03
liuyulongThe L3 meeting is trending to lack of followers and attendees.14:04
liuyulongMaybe we should change the schedule to every 2 weeks.14:05
liuyulongOr merge the meeting with some others, or directly go back to a section during the team meeting.14:06
liuyulongMostly the L3 meeting is mainly aiming on the bugs, and mostly were mentioned before L3 meeting in the team meeting.14:07
haleybhi, sorry, i always have a conflict with a downstream meeting, sometimes forget to join14:07
slaweqI think we can do it biweekly14:07
slaweqbut I don't think we will be able to merge it to team meeting14:08
slaweqas there may be not enough time there to discuss all L3 bugs e.g.14:08
*** yasufum has quit IRC14:09
*** rajivmucheli has left #openstack-meeting14:09
liuyulongSure, thoese are some opinions from me based on my statistics in the last few L3 meetings.14:10
liuyulongSo biweekly is ok to me.14:10
liuyulongAlright, thanks, no more announcement from me.14:11
*** yamamoto has joined #openstack-meeting14:11
*** yamamoto has quit IRC14:11
liuyulongNext14:11
liuyulong#topic Bugs14:11
*** openstack changes topic to "Bugs (Meeting topic: neutron_l3)"14:11
*** yamamoto has joined #openstack-meeting14:12
liuyulong#link http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015707.html14:12
liuyulongSlawek Kaplonski slaweq was our bug deputy last week, thank you.14:12
liuyulongFirst one:14:12
*** sluna has quit IRC14:12
liuyulong#link https://bugs.launchpad.net/neutron/+bug/188490614:12
openstackLaunchpad bug 1884906 in neutron "L3 agent cannot be manually scheduled" [High,Fix released] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)14:12
liuyulongWe have talked about this last week during L3 meeting.14:13
*** sluna has joined #openstack-meeting14:13
liuyulongThe bug https://bugs.launchpad.net/neutron/+bug/1786272 is the long history of this.14:14
openstackLaunchpad bug 1786272 in neutron "Connection between two virtual routers does not work with DVR" [Medium,Fix released] - Assigned to Slawek Kaplonski (slaweq)14:14
liuyulongSorry wrong link...14:15
liuyulong#link https://bugs.launchpad.net/neutron/+bug/188452714:15
openstackLaunchpad bug 1884527 in neutron "Related dvr routers aren't created on compute nodes" [Medium,In progress] - Assigned to Slawek Kaplonski (slaweq)14:15
slaweqI need to check why some functional test is failing there and update this patch14:15
liuyulong#link https://review.opendev.org/#/c/737286/14:16
*** yamamoto has quit IRC14:16
liuyulongslaweq, yes, this is the link of the patch. And unit test cases too. : )14:16
liuyulongI will try the patch after the zuul pass.14:17
*** yasufum has joined #openstack-meeting14:19
liuyulongAllow me share some experiences from our cloud, we have no such "complex" user define topology.14:19
liuyulongIn the production perspective, we define the virtual private cloud (aka VPC) with a router, a external gateway, some networks/subnets and the connections between them.14:21
liuyulongSuch hierarchical topology can introduce a very high load of trouble shooting. And in some cases like VIP, load balance, bare mentel, it is no so much available.14:23
liuyulongSo we directly disable that.14:23
slaweqliuyulong: yes, but we have customers who are using it for some reason14:24
liuyulongBut it is a nice feature of neutron, it is kind of something we called "SDN", software defined network!14:24
slaweqand in fact this is perfectly valid use case14:24
slaweqwhich works fine for topologies other than dvr14:24
liuyulongslaweq, Definitely, it is the cool point that neutron can define such topology.14:26
liuyulongOK, next14:27
liuyulong#link https://bugs.launchpad.net/neutron/+bug/188332114:27
openstackLaunchpad bug 1883321 in neutron "Neutron OpenvSwitch DVR - connection problem" [High,New]14:27
liuyulongThe bug reporter did really nice work.14:28
*** maciejjozefczyk has joined #openstack-meeting14:28
liuyulongWe almost have everything we need.14:28
liuyulongAnd after reading the bug, I noticed that this may be a bug of floating IP migration.14:29
liuyulongchange the compute node L3 agent mode from dvr to dvr_no_external, or conversely.14:29
liuyulongThe floating IPs will lose the connection.14:29
liuyulongIt is not related to the config option "explicity_egress_direct".14:30
liuyulongI will take this one, and test the floating IP migration.14:31
liuyulongFor now, I can say, a valid step to do this work is:14:32
liuyulong1. disassociate the floating IPs14:32
liuyulong2. disable the routers before change the agent mode14:32
liuyulong3. change the agent mode14:32
liuyulong4. enable the routers14:32
liuyulong5. associate the floating IPs back14:33
liuyulongOK, I will paste this to the LP for the reporter.14:33
slaweqk14:33
liuyulongOK, no more L3 bugs from the deputy list.14:34
liuyulongLet's scan the LP list.14:35
liuyulongAlright, a fresh one:14:36
liuyulong#link https://bugs.launchpad.net/neutron/+bug/188592114:36
openstackLaunchpad bug 1885921 in neutron "[RFE][floatingip port_forwarding] Add port ranges" [Undecided,New] - Assigned to Pedro Henrique Pereira Martins (pedrohpmartins)14:36
liuyulongLooks like a nice request of the L3 port forwarding, something like a bulk creation.14:37
liuyulongSeems there is a large scale uses case behind such request.14:38
liuyulongLet's continue the discussion on the LP bug.14:38
liuyulongNext one:14:39
liuyulong#link https://bugs.launchpad.net/neutron/+bug/188589814:39
openstackLaunchpad bug 1885898 in neutron "test connectivity through 2 routers fails in neutron-ovn-tempest-full-multinode-ovs-master job" [High,Confirmed]14:39
liuyulongThis is related to OVN L3, IMO.14:40
slaweqyes14:40
slaweqI opened it today14:40
slaweqand it's only in ovn based scenarios14:40
liuyulongIf this test_connectivity_through_2_routers case blocks the gate/CI alot, maybe we should mark it as unstable.14:42
slaweqliuyulong: no, I saw it failing only in non-voting jobs14:42
slaweqthat's why it's "high" and not "critical"14:43
liuyulongAt least bug 1884527 and 1885898 are all failing on it.14:43
openstackbug 1885898 in neutron "test connectivity through 2 routers fails in neutron-ovn-tempest-full-multinode-ovs-master job" [High,Confirmed] https://launchpad.net/bugs/188589814:43
openstackbug 1884527 in neutron "Related dvr routers aren't created on compute nodes" [Medium,In progress] https://launchpad.net/bugs/1884527 - Assigned to Slawek Kaplonski (slaweq)14:43
*** diurnalist has joined #openstack-meeting14:44
liuyulongslaweq, OK14:45
liuyulongAlright, no more bugs from LP list then.14:45
liuyulongAny updates?14:45
slaweqI have one old to talk about14:45
liuyulongSure14:45
slaweqhttps://bugs.launchpad.net/neutron/+bug/177445914:45
openstackLaunchpad bug 1774459 in neutron "Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,In progress] - Assigned to Brian Haley (brian-haley)14:45
slaweqthere is patch https://review.opendev.org/#/c/601336/ which I think is last missing bit to solve that14:46
slaweqliuyulong but as You had many comments there, I wanted to ask if You think we should/can move on with this one14:47
slaweqor maybe do You have some other idea about how to solve this issue14:47
*** armax has joined #openstack-meeting14:47
* liuyulong opening the link...14:47
*** LiangFang has quit IRC14:48
liuyulongOK, I see that.14:48
liuyulongThis is really a tough one.14:48
liuyulongThe current fix is relying on the garp sending out from the VM.14:49
slaweqyes14:49
slaweqwhen additional IP is configured there14:49
*** dklyle has joined #openstack-meeting14:49
liuyulongThis could be the main risk of the fix, neutron is rely on something which is out of control.14:50
slaweqyes but do You have any other idea how to solve this?14:51
*** Liang__ has joined #openstack-meeting14:51
slaweqand also main use case for that is using e.g. keepalived and it sends garps when configures IP on the host14:51
liuyulongWhat if the garp is not out? Or there are some tools which does not send garp by default?14:52
slaweqso in this use case it would be fine14:52
liuyulongyep, for keepalived for now.14:52
slaweqI see Your point but if tool/vm is not informing us that it is using this IP now actually, how we can know that?14:52
liuyulongI have an potential alternative of the fix which based on arp proxy.14:53
liuyulongIt may work.14:53
liuyulongI have not tested it yet.14:54
haleybi don't think there's a perfect solution, this area has always been "should be good enough for most" unfortunately14:54
liuyulonghaleyb, agreed, so maybe each solution can be configurable.14:55
*** links has quit IRC14:55
liuyulongthen the end user can choose their best way.14:56
liuyulongslaweq, arp proxy on the qr-device for those VIPs cross the subnets.14:56
slaweqIMHO for now we have use cases with keepalived for which garps should be ok and we should focus to address that14:56
haleybthat might lead to confusion having two ways with a config option14:57
slaweqif we will have other valid use case which isn't addressed with such solution we can think about other and about some config switch14:57
haleybslaweq: my next question is how would OVN do this? :)14:57
slaweqhaleyb: I'm not even sure if that is the issue in case of ovn14:58
haleybthat would be good14:58
slaweqAFAIU this issue is strictly related with how dvr works14:58
slaweqe.g. in L3ha it should works fine probably14:58
liuyulongmaybe we should test the VIP for OVN in east-west connections.14:58
slaweqbut that would need to be tested probably14:58
liuyulong#link https://bugs.launchpad.net/neutron/+bug/185963814:59
openstackLaunchpad bug 1774459 in neutron "duplicate for #1859638 Update permanent ARP entries for allowed_address_pair IPs in DVR Routers" [High,In progress] - Assigned to Brian Haley (brian-haley)14:59
liuyulongIt is marked as duplicated.14:59
liuyulongThe title is "VIP between dvr east-west networks does not work at all".14:59
slaweqI think we are over time today15:00
liuyulongOK, time is up.15:00
liuyulongThank you guys for the discussion.15:01
liuyulong#endmeeting15:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"15:01
openstackMeeting ended Wed Jul  1 15:01:24 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/neutron_l3/2020/neutron_l3.2020-07-01-14.02.html15:01
slaweqthx15:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/neutron_l3/2020/neutron_l3.2020-07-01-14.02.txt15:01
openstackLog:            http://eavesdrop.openstack.org/meetings/neutron_l3/2020/neutron_l3.2020-07-01-14.02.log.html15:01
*** manuvakery has quit IRC15:12
*** _mlavalle_1 has joined #openstack-meeting15:19
*** mlavalle has quit IRC15:22
*** Liang__ has quit IRC15:33
*** jiaopengju1 has quit IRC15:45
*** jiaopengju1 has joined #openstack-meeting15:46
*** yasufum has quit IRC15:48
*** ricolin has quit IRC16:01
*** liuyulong has quit IRC16:05
*** armax has quit IRC16:06
*** ttsiouts has quit IRC16:06
*** ttsiouts has joined #openstack-meeting16:07
*** ttsiouts has quit IRC16:11
*** armax has joined #openstack-meeting16:11
*** etp has quit IRC16:16
*** etp has joined #openstack-meeting16:19
*** etp has quit IRC16:24
*** etp has joined #openstack-meeting16:44
*** ociuhandu_ has joined #openstack-meeting16:45
*** ociuhandu has quit IRC16:49
*** ociuhandu_ has quit IRC16:52
*** Lucas_Gray has quit IRC16:53
*** Lucas_Gray has joined #openstack-meeting16:58
*** ociuhandu has joined #openstack-meeting16:59
*** rh-jelabarre has quit IRC16:59
*** rh-jelabarre has joined #openstack-meeting16:59
*** psahoo_ has quit IRC17:01
*** ociuhandu has quit IRC17:07
*** psahoo_ has joined #openstack-meeting17:08
*** ralonsoh has quit IRC17:10
*** ralonsoh has joined #openstack-meeting17:10
*** psahoo_ has quit IRC17:11
*** corvus has quit IRC17:15
*** bnemec has quit IRC17:15
*** rledisez has quit IRC17:15
*** mattoliverau has quit IRC17:15
*** timburke has quit IRC17:15
*** jamespage has quit IRC17:15
*** ericyoung has quit IRC17:15
*** freefood has quit IRC17:15
*** jamespage has joined #openstack-meeting17:18
*** corvus has joined #openstack-meeting17:18
*** ericyoung has joined #openstack-meeting17:18
*** timburke has joined #openstack-meeting17:18
*** freefood has joined #openstack-meeting17:18
*** bnemec has joined #openstack-meeting17:21
*** johanssone has quit IRC17:26
*** freerunner has quit IRC17:26
*** yoshito-ito has quit IRC17:26
*** hongbin has joined #openstack-meeting17:28
*** irclogbot_3 has quit IRC17:28
*** gyee has joined #openstack-meeting17:29
*** johanssone has joined #openstack-meeting17:29
*** freerunner has joined #openstack-meeting17:29
*** yoshito-ito has joined #openstack-meeting17:29
*** irclogbot_1 has joined #openstack-meeting17:30
*** Lucas_Gray has quit IRC17:30
*** njohnston_ has joined #openstack-meeting17:43
*** njohnston has quit IRC17:43
*** yamamoto has joined #openstack-meeting17:44
*** njohnston_ is now known as njohnston17:45
*** yamamoto has quit IRC17:53
*** e0ne has quit IRC17:59
*** eharney has quit IRC18:16
*** slaweq has quit IRC18:25
*** dasp_ has quit IRC18:39
*** dasp has joined #openstack-meeting18:41
*** hongbin has quit IRC18:44
*** dklyle has quit IRC18:54
*** dklyle has joined #openstack-meeting19:02
*** ociuhandu has joined #openstack-meeting19:06
*** _mlavalle_1 has quit IRC19:10
*** _mlavalle_1 has joined #openstack-meeting19:15
*** hongbin has joined #openstack-meeting19:18
*** yoctozepto7 has joined #openstack-meeting19:37
*** tris has quit IRC19:45
*** yoctozepto has quit IRC19:45
*** yoctozepto7 is now known as yoctozepto19:45
*** tris- has joined #openstack-meeting19:45
*** tris- is now known as tris19:45
*** vishalmanchanda has quit IRC19:47
*** ralonsoh has quit IRC19:50
*** eharney has joined #openstack-meeting19:59
*** hongbin has quit IRC20:06
*** e0ne has joined #openstack-meeting20:20
*** slaweq has joined #openstack-meeting20:25
*** maciejjozefczyk has quit IRC20:36
*** jgriffith has quit IRC20:54
*** hongbin has joined #openstack-meeting20:54
*** alecuyer has joined #openstack-meeting20:57
*** patchbot has joined #openstack-meeting20:59
timburke#startmeeting swift21:00
openstackMeeting started Wed Jul  1 21:00:06 2020 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.21:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.21:00
*** openstack changes topic to " (Meeting topic: swift)"21:00
openstackThe meeting name has been set to 'swift'21:00
timburkewho's here for the swift meeting?21:00
kota_o/21:00
alecuyero/21:00
seongsoochoo/21:00
clayghowdy!21:00
timburkeagenda's at https://wiki.openstack.org/wiki/Meetings/Swift21:02
timburkefirst up21:02
timburke#topic Berlin21:02
*** openstack changes topic to "Berlin (Meeting topic: swift)"21:02
timburkethe Request for Presentations recently opened up21:02
timburke#link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/015730.html21:02
timburkedeadline's Aug 421:02
timburkesummit will be Oct 19-2321:03
*** ircuser-1 has quit IRC21:03
timburke(assuming pandemic is more or less under control, so... who knows?)21:03
kota_:/21:04
timburkebut i wanted to at least bring the call for presentations to everyone's attention21:04
timburkethat's all i've got in terms of announcements21:05
timburke#topic replication servers21:05
*** openstack changes topic to "replication servers (Meeting topic: swift)"21:05
timburkeso clayg made a very important observation on p 73575121:05
patchbothttps://review.opendev.org/#/c/735751/ - swift - Allow direct and internal clients to use the repli... - 4 patch sets21:05
clayggo team!21:06
timburkethe replication servers currently only respond to SSYNC and REPLICATE requests!21:06
timburke#link https://bugs.launchpad.net/swift/+bug/144687321:06
openstackLaunchpad bug 1446873 in OpenStack Object Storage (swift) "ssync doesn't work with replication_server = true" [Medium,Confirmed]21:06
timburkeit won't even respond to OPTIONS, which is supposed to tell you what request methods *are* allowed21:07
*** mattoliverau has joined #openstack-meeting21:07
clayg^ that's like @timburke 's favorite joke 🤣21:07
*** e0ne has quit IRC21:07
mattoliverauSorry I'm late, woke up this morning and had IRC troubles, but finally connected.21:08
timburkeit looks like it won't be too hard to allow replication servers to service all requests, and make `replication_server = False` basically mean "don't do SSYNC or REPLICATE"21:08
timburkedoes that seem like a reasonable thing to everyone, though?21:08
timburkei feel like the work involved in making it so i can properly *test* with separate replication servers is going to be way bigger than making it work :-/21:10
claygI think the conclusion on the lp bug was drop the semantic of `replicatoin_server = None` - which I think is what you HAVE to run on your replication server's now if you want to do a replication netowork and have EC rebuild still work21:12
timburkeseems related to https://review.opendev.org/#/c/337861/ 🤔21:13
patchbotpatch 337861 - swift - Permit to bind object-server on replication_port - 7 patch sets21:13
claygyeah probably 😬21:13
claygi feel like if this was easy we wouldn't have put it off so long21:13
claygit would be helpful to have sanity checks as we try to merge shit21:14
timburkeit's probably worth me putting in some work to make probe tests runnable with separate replication servers regardless. seems like a lot of people run that way (we certainly do!) and anything i can do to make my dev environment more representative of prod seems like a good idea21:15
timburkebut, it'll probably be a bit21:15
timburke#topic waterfall EC21:15
*** openstack changes topic to "waterfall EC (Meeting topic: swift)"21:15
timburkeclayg, how's it going?21:16
claygtimburke: it's a non-zero cost to have to run a second set of backend *-server, but could be nice21:16
claygtimburke: you're the only one who's commented 😠21:16
timburkehehe21:16
timburkefair enough21:16
claygi'm really proud of my little feeder system tho - I've started to conceptualize breaking them up as like a poly rhythm sort of situation21:17
claygwhere we have on flow of code that's popping ticks predictably (start ndata, then remaining nparity at a predictable pattern)21:17
claygthen there's this *other* beat that's all random just based on when stuff responds21:17
claygdoing that all in one loop was maddness - two loops is better21:18
claygand then I'm also proud of the logic simplifications that I'd managed to get so far - but it was super helpful to have another brain load it up and WTF at it21:18
claygsome bits are still confusion - but I was desensitized21:18
*** slaweq has quit IRC21:19
timburkeso, anyone else have some bandwidth to take a look in the next week or two?21:19
claygyou were talking about good buckets and bad buckets and 416 as success ... there might be more cleanup, but I'd need some sort of "bad behavior" to really motiviate me to "get back in there"21:19
claygotherwise it's just pushing symbols around for subjective qualities21:20
alecuyerI think I can at least try the patch next week, I should have more time than these past weeks21:20
claygI'm happy with the tradeoffs for "the non-durable problem" - I know were never did that zoom or w/e - but it's fine (i'm still happy to answer questions as needed)21:20
timburkealecuyer, thank you21:20
claygthe final patch - the "make timeouts configurable per replica"21:21
claygit's... a little "much" by some estimations.  I like the expressiveness; but worry it's the same as the pipeline problem 😞21:21
*** priteau has quit IRC21:21
claygthe more people who would be willing to put on their operator hat and try to grok what those options even *mean* THE BETTER21:22
claygif I can explain it to YOU guys trivially there's no hope I'll ever be able to write clear docs21:22
alecuyerok21:22
timburkewould it be worth us documenting them as experimental/subject to change (or even removal)? just as soon as we get a chance to have a better option21:22
claygThen the last gotcha is the final fate of ECFragGetter - do we trim it down lean and mean and try to pull all remains of EC out of GETorHEADHandler - or is there still some hope we can unify them some way that's sane?21:23
claygIt's really not clear to me; and I guess I'm avoiding trying to code that I'm not confident is a good idea 👎21:24
claygtimburke: I think that'd be reasonable if after everyone looks at them we have some different ideas about directions we might go; or the best we can come up with seems like a lot of work21:24
claygif we look at them and say "yeah, per policy; per replica - makes sense" then we just write that down with some common examples/patterns and move on21:25
claygso I think I really could use some feedback right now - from anyone who has cycles - you don't have to grok all the code; or even check out the change21:26
claygreading the example config in the final patch (based on the converstations we been having) and providing feed back there is a great start21:26
timburkeone thing i'm definitely digging is the fact that it's available as a per-policy option immediately -- i think it'll be really handy for a lab cluster to be able to define, say, five EC policies that are identical except for those tunings21:26
mattoliverauI'll make sure I have a look this week, especially big picture so can comment of config options. If I have time I'll try and go a little deeper.21:27
claygif you can glance through some of the weird corners of how ECFragGetter is starting to diverge from GETorHEADHandler and give me a gut check "yeah probably different enough" or "these smell like minor differences" would also be helpful21:27
timburke#link https://review.opendev.org/#/c/73709621:27
patchbotpatch 737096 - swift - Make concurrency timeout per policy and replica - 3 patch sets21:27
claygif you can grok that main ec-waterfall loops - even setting aside weird bucket stuff like shortfall and durable - that'd like above and beyond21:28
timburke(just realized i had a few comments i forgot to publish)21:28
claygat that point you may as well check it out and try to configure it - it probalby wouldn't take much work to see that it DOES do what it says on the tin21:28
claygTHANK YOU ALL SO MUCH!!!  feedback is what I need - couldn't do this without y'all - GO TEAM!21:29
timburkeall right21:29
timburke#topic open discussion21:29
*** openstack changes topic to "open discussion (Meeting topic: swift)"21:29
timburkewhat else do we need to bring up today?21:30
clayglibec !!!21:30
claygso we definately have the old style checksum frags...21:30
claygeveryone run this on your EC .data files -> https://gist.github.com/clayg/df7c276a43c3618d7897ba50ae87ea9d21:30
claygif your hash matches zlib you're golden!  upgrade to >1.16 and rejoice!21:31
claygif you've got that stupid stupid stupid libec inline checksums - you're probably gunna be stuck with them for awhile (and also don't upgrade - you'll die)21:31
alecuyerthanks for that snippet clay21:32
claygwell... you might die anyway because 1.15 was like... somehow indeterminate?21:32
timburkewell, until everything upgrades ;-)21:32
claygso we have to do better; but 1.16 isn't quite good enough21:32
claygalecuyer: timburke wrote it21:32
timburkeso, it seems like we need a way to tell libec to continue writing old frags21:33
mattoliverauwow, nice useful bit of coding there!21:33
timburkewe also almost certainly need to write a detailed bug ;-)21:34
claygright, for us to upgrade we need new code to not start writing in the new format yet because old nodes won't know what to do with that shit until the upgrade21:34
claygI think we could probably just like... "upgrade libec real fast and restart everything!"21:34
claygbut... we'll probably like "be careful" or whatever 🙄21:34
claygI'm gunna try to talk timburke into a *build* option that's just like "always write the old stupid inline crc value forever"21:35
claygthat way I can just make it WOMM and then ship it and never thing about how much i hate C again21:35
alecuyerhehe21:36
claygbut... it might not work - timburke is pretty sure we should actually use the zlib version as soon as we can - so an env var with a portable build might be "better"21:36
claygif by "better" is - you'd rather pay some operational cost to rollout with the latch; then after upgrade remove the latch; and then be on the path of righteousness forever fighting back the forces of kludge and evil21:37
timburkeyeah, i'm still fairly nervous that our funky crc doesn't have the same kinds of guarantees that we're expecting from zlib...21:38
claygtimburke: well i'm not sure I can write controller code that can do the upgrade properly!  like... we'd have to do a checkpoint release or something 🤮21:39
claygI'm sure I could build a packge with an option that's like CLAYG_IS_TOO_LAZY_TO_DO_THIS_RIGHT=True21:39
timburkeside note on all of this: thank you alecuyer for noticing this and bringing it up last week! much better to be arguing about how best to navigate this now than mid-upgrade ;-)21:39
claygand then if at somepoint you're sure all legacy swiftstack customers have upgrade you turn that off ;)21:39
claygyeah FOR SURE - alecuyer is god send ❤️21:40
*** haleyb has quit IRC21:40
alecuyerthanks but I wish i'd do more - and be faster.. :) but thanks21:40
timburkeclayg, we could totally have a controller that always says "write legacy crcs" -- we've done controller checkpoint releases before; after the next one, we tell it to switch over21:40
claygyeah, again - if we can couple it to an upstream swift change that makes it just an ini/config var I'm totally down21:41
claygif I have to update our systemd units in the package to turn it on/off i'm pretty sure I'm too dumb to get it right21:42
claygalecuyer: kota_: mattoliverau: if you have access to any EC data in any cluster anywhere please see if you can get the crc thing to run on it and report back w/i a couple of weeks21:42
claygwe'll probably kick this can down the road for awhile (1.15 is working fine for me!)21:43
claygthat's all I got on libec21:43
alecuyeryep, will do21:43
timburkeanybody think they'll have a chance to look at https://review.opendev.org/#/c/737856/ ? it seems to be working well for ormandj21:43
patchbotpatch 737856 - swift - py3: Stop munging RAW_PATH_INFO - 2 patch sets21:44
timburkei'd like to backport it to ussuri and train, then ideally do a round of releases21:44
claygtimburke: oh neat - is the test new?21:45
timburke(probably should have done that earlier, but now that there's an additional known issue...)21:45
timburkeyeah21:45
claygb"GET /oh\xffboy%what$now%E2%80%bd HTTP/1.0\r\n" 🤣21:45
timburkeoh, and as a heads-up: it looks like there might be some movement on an eventlet fix for that py37/ssl bug21:46
timburke#link https://github.com/eventlet/eventlet/pull/62121:46
alecuyersounds good!21:47
timburkeall right, last call21:49
timburkethank you all for coming, and thank you for working on swift!21:50
timburke#endmeeting21:50
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"21:50
openstackMeeting ended Wed Jul  1 21:50:33 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:50
openstackMinutes:        http://eavesdrop.openstack.org/meetings/swift/2020/swift.2020-07-01-21.00.html21:50
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/swift/2020/swift.2020-07-01-21.00.txt21:50
openstackLog:            http://eavesdrop.openstack.org/meetings/swift/2020/swift.2020-07-01-21.00.log.html21:50
*** patchbot has left #openstack-meeting21:50
*** haleyb has joined #openstack-meeting21:52
*** rcernin has joined #openstack-meeting22:37
*** rcernin has quit IRC22:47
*** rcernin has joined #openstack-meeting22:47
*** ykatabam has joined #openstack-meeting22:51
*** TrevorV has quit IRC22:54
*** jmasud has quit IRC23:01
*** jmasud has joined #openstack-meeting23:03
*** _mlavalle_1 has quit IRC23:11
*** hongbin has quit IRC23:11
*** moguimar has quit IRC23:14
*** hongbin has joined #openstack-meeting23:16
*** Lucas_Gray has joined #openstack-meeting23:21
*** rfolco has quit IRC23:48
*** yamamoto has joined #openstack-meeting23:52
*** yamamoto has quit IRC23:57
*** yasufum has joined #openstack-meeting23:58

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