21:00:00 #startmeeting swift 21:00:01 Meeting started Wed Jan 22 21:00:00 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:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:05 The meeting name has been set to 'swift' 21:00:08 who's here for the swift meeting? 21:00:28 o/ 21:00:31 o/ 21:00:32 o/ 21:00:49 o/ 21:00:54 o/ 21:01:02 o/ 21:01:25 not too much on the agenda: https://wiki.openstack.org/wiki/Meetings/Swift 21:01:30 mainly i want to talk about 21:01:35 #topic upcoming release 21:01:57 p 701497 has merged 21:01:57 https://review.opendev.org/#/c/701497/ - swift - py3: Fix formpost unicode filename issues (MERGED) - 3 patch sets 21:02:13 p 701736 is working its way through the gate 21:02:14 https://review.opendev.org/#/c/701736/ - swift - Allow bulk to fwd some headers at tar extraction - 3 patch sets 21:02:54 which means there's just two (kind of three) bodies of work i'd like to see land before cutting a release 21:03:03 p 702650 21:03:04 https://review.opendev.org/#/c/702650/ - octavia-tempest-plugin - Add scenario test for IPv6 VIP and IPv6-only members - 1 patch set 21:03:24 er, no -- p 702950 21:03:25 https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets 21:04:01 (and maybe its follow-on, p 703155) 21:04:01 https://review.opendev.org/#/c/703155/ - swift - Store normalized x-delete-at on PUT/POST - 3 patch sets 21:04:14 and versioning 21:05:04 so lp bug #1860149 - is there any downside to landing p 702950 21:05:04 Launchpad bug 1860149 in OpenStack Object Storage (swift) "Large X-Delete-At values cause object-server to 500" [High,In progress] https://launchpad.net/bugs/1860149 21:05:04 https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets 21:05:04 so first -- can anyone volunteer to review the timestamp patch? i'd kinda like to let seongsoocho's customers access their data again ;-) 21:05:36 yeah, i agree lp bug #1860149 is pretty awful 21:06:14 ouch 21:06:26 clayg, i don't think so -- i guess the only question left in my mind is whether we should 400 delete-ats that are more than, say, 100 years in the future 21:06:31 I mean I can "review" p 702950 - but the only contribution that'll really come out of it is a func test change to follow on and a +A 🤣 21:06:31 https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets 21:06:32 i'll be back to https://review.opendev.org/#/c/702950/ 21:06:33 patch 702950 - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets 21:07:50 thanks clayg and kota_! your input will be invaluable, i'm sure :-) 21:07:59 #topic versioning 21:08:47 so i think i'd still like this ahead of a release -- does anyone worry that we should tag sooner rather than wait for it? 21:11:06 timburke: just to clarify who you're asking - kota_ or alecuyer or seongsoocho, right? SwiftStack already shipped it - but I hear we're still waiting on the customer to upgrade, so we'd definately like to get a tag on it. 21:12:44 either is fine to me, any tagged point will be acceptable from my org. 21:12:46 waiting until the patches you mentionned are in sounds reasonnable 21:13:08 clayg, yeah, i suppose so -- though a fresh tag with fresh features would also mean we'll likely see new bug reports that increases *your* support burden, too ;-) 21:13:57 timburke: mostly *yours* but... also it'd be nice to have sweet shiny changelog! 21:14:17 hell yeah it would be! 21:14:23 between p 682382 and p 698139 i think the swift API is pretty solid -- the only thing i'm still wavering on is whether/how we ought to deal with primary containers that (for whatever reason) don't have their %00versions%00 container even though they've got metadata thinking that they should 21:14:24 https://review.opendev.org/#/c/682382/ - swift - New Object Versioning mode - 74 patch sets 21:14:26 https://review.opendev.org/#/c/698139/ - swift - Skip container-sync when versioning enabled - 14 patch sets 21:14:34 kota_: alecuyer: I really hope you're gunna like versioning, @timburke and @tdasilva worked really hard on it, and I think it's pretty great 21:14:35 I don't have the changelog in mind, but the versioning/null sperator seems the bug thing of this release, one is only something if it is enabled, the other I guess is only used by versioning. so having it in the next release does not seem an issue 21:14:50 *the big thing 21:15:11 Freudian slip ;-) 21:15:13 so i guess both options are fine for me 21:16:14 clayg: +100, I support the work. I don't have much time to look the spec for now but I trust the authors. 21:16:40 my question on the swift api is: should we make sure that case is covered/tested, or does it seem sufficiently unlikely that we'd be ok with addressing it in a follow-up (potentially after a release) 21:17:30 timburke: right it's impossible to say how that situation resolves symantically eventually - so we either leave it undefined or pick how it should be (either way seems reasonable to me) 21:18:03 timburke: I *think* (but not have a string opinion for now) I would not enable the new versioning until the container-sync is working with it, because it would create confusion for sure to our customers 21:18:25 we should at least make it possible for ops to fix it, right now i think they would have to delete the primary container all together, which isn't great 21:18:28 oh no! bummer... 21:19:23 tdasilva: oh, ideally re-issuing the enable versioning request would soome how make sure the versions container was available for subsequent requests 21:20:01 clayg: +1 21:20:13 tdasilva, if we're talking ops, they could use a direct client to pop the reserved container back into existence -- but yeah, i'd like it to be something an external client can fix 21:20:16 i think it would be nice to fix that 21:20:38 so, before or after a merge? ;-) 21:20:50 heh, that's the question! 21:21:00 ahahah, if it's a bug we can demonstrate it should be before! 21:21:11 i'd say, let's mere as is, and follow-up patch before release 21:21:25 maybe I'll fix it and merge it before you guys find anymore - then we can start tracking and prioritizing them in launchpad 21:21:34 can't you just create it on any new put request? But I guess I don't understand the problem. I'd hope if they magically came back (sitting on a power off node) they'd just sync back up. 21:22:16 but, I'm sure there is something obvious I'm missing. /me will try and take a look at the code now that I'm back home. 21:22:17 tdasilva: that's an ok idea - I have merged things while opening new bugs because they seemed sufficiently orthoganal - but it was never a "that's minor" kind of thing 21:22:20 mattoliverau: currently no, and that's what needs to be fixed 21:22:56 mattoliverau: no, i agree - most likly this out of sync conditions are temporary 21:23:09 clayg: I'm just trying to avoid we get to 100 patchset mark :D 21:23:17 lol 21:23:40 but I suppose it's possible the way it's implemented the client just say what they want and continue on their way - they have to wait for the cluster to fix something at somepoint... and tdasilva and timburke say that should be something a client should be able to fix right away 21:23:44 tdasilva, that's still like 25, 26 away! lot's of time :P 21:23:50 tdasilva: LOL 21:24:22 tdasilva: i can really HEAR your voice in my head when you say that!!! 😍 21:25:11 timburke: tdasilva: was that the only issue? 21:25:29 timburke: tdasilva: it sounds like we might be the only ones using it for awahile (like OVH is stuck with container-sync) 21:25:31 that we know of :/ 21:26:08 well I just mean that probably makes it easier to merge and just open a bug on lp - you can assign the bug to me if you want 21:26:22 I was ready to merge it last week and I'm sure it's only gotten better 👍 21:26:23 i think that's my big blocker. there are a couple other funny things i've found, mostly to do with listings -- very minor things. limit not being respected in some non-happy-path cases, stuff like that 21:27:27 timburke: ok, we'll if you got some stuff in your head already you want to unload before we merge it that's fine - let's get to it 21:28:03 eh, i'd be fine with fixing up listings in follow-ups 21:28:14 on the s3 patch 673682 though... i've got a few more worries 21:28:14 https://review.opendev.org/#/c/673682/ - swift - s3api: Implement object versioning API - 45 patch sets 21:28:27 i need to get more of that loaded into my head i think 21:28:42 oh, ok then! 21:30:50 that said, though, part of the reason for having them as separate patches was that they're separate (if dependent) features and we could merge to s3 one later 21:31:38 timburke: yeah that's find - do you want to merge versoining; then tag; then probably merge s3api support after that? 21:32:06 clayg, that's one of the things i'm debating about 21:32:39 won't help with release notes tho 21:32:45 honestly, i'm not sure 21:33:02 ok, well step 1 is the versioning - and it sounds like you could use some help - is ther a repro/setup script/test for the split container or listing things? 21:33:20 or... just a bunch of review comments somewhere between patch #10-#86? 21:33:20 No data found for patch 10 21:33:22 maybe i should just push up my edits to the s3 patch and let it go in, too 21:33:43 well, you should definately push up your edits :D 21:34:09 clayg, enable versioning on a container, then use an internal client or something to go delete the versions container 21:35:48 we've already got a probe test that exercises the converse; i just haven't gotten around to writing this test yet 21:36:50 all right, sounds like we've got something of a plan for how what to do next on versioning... 21:36:57 #topic open discussion 21:37:08 does anyone have anything else they'd like to bring up? 21:40:23 all right, then 21:40:34 thank you all for coming, and thank you for working on swift! 21:40:40 #endmeeting