21:00:59 #startmeeting swift 21:01:00 Meeting started Wed Mar 25 21:00:59 2020 UTC and is due to finish in 60 minutes. The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:03 The meeting name has been set to 'swift' 21:01:06 who's here for the swift meeting? 21:01:09 o/ 21:01:13 hi 21:01:13 o/ 21:01:41 o/ 21:01:46 hi 21:01:47 o/ 21:02:29 agenda's at https://wiki.openstack.org/wiki/Meetings/Swift 21:02:36 #topic surveys 21:02:53 the 2020 user survey is out! 21:03:00 #link https://www.openstack.org/user-survey/survey-2020/ 21:03:42 help inform the foundation/tc/projects about what's getting used and how, and where things could be improved :-) 21:04:10 there's *also* some kind of special survey going on... 21:04:13 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-March/013577.html 21:04:28 which references... 21:04:29 #link https://openstackfoundation.formstack.com/forms/10_years_of_openstack 21:05:48 i don't think there's much more to say about them. they exist, i plan on filling them out :-) 21:05:55 o/ 21:06:14 #topic virtual PTG 21:06:33 i created an etherpad to start collecting topic 21:06:39 #link https://etherpad.openstack.org/p/swift-ptg-victoria 21:07:49 i think it's going to be interesting making this be a good, useful time for us, but i know we're up for it 21:07:52 it sux that the PTG was cancelled, but actually works out well for me :) 21:08:16 me too :-) i wasn't going to be able to go otherwise 21:08:31 :-) 21:08:34 \o/ 21:10:11 as it gets closer, i'll send out some surveys about what time slots people will be around for -- i wonder if it might make sense to stagger the times over the course of the week, with the expectation that not everyone will attend every session 21:10:46 sounds good 21:11:30 otoh, clayg and i both seem to post reviews at all hours, so maybe we just optimize for asia/europe and make it work :P 21:11:43 (hopefully rledisez and tdasilva don't kill me ;-) 21:12:13 things to consider, anyway 21:12:28 lol 21:12:29 i'm pretty sure I can make it, I'm kinda an early bird usually ;) 21:12:57 that's all i had by way of announcements -- any comments or questions on them? 21:14:11 on to updates! 21:14:14 Kernel used to run over e-mail. It took me a while to get used to how meeting-happy OpenStack was. 21:14:51 #topic waterfall EC 21:15:12 clayg, i heard you were working on a third attempt 21:18:16 maybe it's still not to a point worth bringing up ;-) 21:19:29 i remember hearing admiration for torgomatic, and having everything feel almost-but-not-quite related enough to have it all make sense 21:19:38 #topic lots of small files 21:19:51 alecuyer, rledisez, how's it going? 21:20:06 I posted some patches we had there we had not pushed, thanks Tim for looking at these 21:20:18 👍 21:20:20 Otherwise, I have been running POCs about volume selection when writing, and storing object metadata in the DB. That's about it 21:20:57 sounds good 21:21:29 i'm still a little unsure about what to do for p 713914 21:21:30 https://review.opendev.org/#/c/713914/ - swift (feature/losf) - Add a sleep() between index-server health checks - 1 patch set 21:22:34 I think I will remove the hardcoded sleep(10) from the other patch that prompted this one, so we can go ahead and think about how to do handle the health checks properly on slow machines 21:22:46 it sounds like you have a similar sleep added in the replicator & reconstructor -- but rledisez and zaitcev seemed hesitant to turn it into a config option... should we just bump up the timeout? or ... something else? 21:23:35 I think for replicator/reconstructor we can just do a getmtime() on ring and optimize it. though, 0.1 second is like really small, maybe bump it a little (like 1s, 2 s?) 21:23:49 I was hoping that 0.01 would be sufficient for everyone. 21:23:57 for LOSF, I don't know it we can "optimize" the current check or if bumping the sleep is the only solution 21:24:35 I can cache that result a few seconds in the health check - but we also have the issue with "regular" daemons, on atom CPUs 21:27:28 I'm thinking, currently, there is only non-essential daemon that use this class (replicator, reconstructor, …), right? it can't hurt to be a little slower to spawn new process. it can even save of a situation where process is just diying and is respawned continuously 21:28:01 non-essential == not in the data-path 21:28:25 seems reasonable 21:28:48 thanks 21:29:10 #topic cors 21:29:47 so i've tried to get a minimal chain for the s3api change that i'm actually looking for 21:30:20 p 533028, p 710330, p 710355 21:30:20 https://review.opendev.org/#/c/533028/ - swift - Add some functional CORS tests - 11 patch sets 21:30:22 https://review.opendev.org/#/c/710330/ - swift - s3api: Pass through CORS headers - 7 patch sets 21:30:23 https://review.opendev.org/#/c/710355/ - swift - s3api: Allow CORS preflight requests - 10 patch sets 21:31:26 i know clayg has looked at the new cors tests long enough to kick out p 713754 and p 714714, thanks! 21:31:26 https://review.opendev.org/#/c/713754/ - swift - Move cors out of functests (ABANDONED) - 2 patch sets 21:31:28 https://review.opendev.org/#/c/714714/ - swift - Add &test= query param to CORS test infra - 1 patch set 21:32:14 but i also got a sense that he's hesitant to take on maintaining some new one-off javascript testing framework (which is fair) 21:33:43 how does everyone else feel about that? i just don't know how i can get a feel for how cors works without writing some javascript... 21:35:55 I assume there is no way to simulate a browser behavior without a real browser javascript? 21:36:13 could it be an external service that do that? I don't like it, but the day that service change… 21:37:13 i suppose i could... but i'd really worry about how well it'd actually match what real browsers *do* -- i've already spotted places where browsers don't interpret the spec the same way, so different headers get exposed depending on which browser you're using 21:37:31 see p 712238 21:37:32 https://review.opendev.org/#/c/712238/ - swift - cors: Add Content-Length to default-exposed headers - 5 patch sets 21:42:09 something to think about, anyway. maybe i should look at writing some (python) func tests for those; between func & unit i'd feel pretty good about us being unlikely to regress, so maybe we could flip the order on the chain and let p 533028 be a separate, longer discussion... 21:42:10 https://review.opendev.org/#/c/533028/ - swift - Add some functional CORS tests - 11 patch sets 21:42:26 timburke: didn't you try to use Selenium? 21:43:21 zaitcev, yep, that patch adds a new gate job that uses selenium to drive a headless browser to exercise some javascript 21:43:39 the question is, do we really want to maintain javascript ;-) 21:44:17 i like the diff i got at https://review.opendev.org/#/c/710355/10/test/cors/test-s3-obj.js with the chain the way it is, though 21:44:18 patch 710355 - swift - s3api: Allow CORS preflight requests - 10 patch sets 21:44:55 CorsBlocked -> S3ObjectOK sure feels like a win :D 21:46:35 well, that was the main question i still had 21:46:40 #topic open discussion 21:46:48 anything else to bring up this week? 21:49:01 Well, I'm still beating the drum for the dark data watcher. 21:49:18 Romain took a look, and I think I mostly answered his remarks. 21:49:25 Or completely. 21:50:34 zaitcev: I'll go check that again 21:51:31 i'll try to take a look this week, too. there's a project i'm looking at where we somehow got some orphaned shards, so it seems not-so-crazy to me that there might be some dark data, too, by the time i've got *that* cleaned up 21:52:11 all right, thank you all for coming and thank you for working on swift! 21:52:16 #endmeeting