21:00:00 <timburke> #startmeeting swift
21:00:01 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:05 <openstack> The meeting name has been set to 'swift'
21:00:08 <timburke> who's here for the swift meeting?
21:00:28 <alecuyer> o/
21:00:31 <mattoliverau> o/
21:00:32 <rledisez> o/
21:00:49 <tdasilva> o/
21:00:54 <clayg> o/
21:01:02 <kota_> o/
21:01:25 <timburke> not too much on the agenda: https://wiki.openstack.org/wiki/Meetings/Swift
21:01:30 <timburke> mainly i want to talk about
21:01:35 <timburke> #topic upcoming release
21:01:57 <timburke> p 701497 has merged
21:01:57 <patchbot> https://review.opendev.org/#/c/701497/ - swift - py3: Fix formpost unicode filename issues (MERGED) - 3 patch sets
21:02:13 <timburke> p 701736 is working its way through the gate
21:02:14 <patchbot> https://review.opendev.org/#/c/701736/ - swift - Allow bulk to fwd some headers at tar extraction - 3 patch sets
21:02:54 <timburke> 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 <timburke> p 702650
21:03:04 <patchbot> 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 <timburke> er, no -- p 702950
21:03:25 <patchbot> https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets
21:04:01 <timburke> (and maybe its follow-on, p 703155)
21:04:01 <patchbot> https://review.opendev.org/#/c/703155/ - swift - Store normalized x-delete-at on PUT/POST - 3 patch sets
21:04:14 <timburke> and versioning
21:05:04 <clayg> so lp bug #1860149 - is there any downside to landing p 702950
21:05:04 <openstack> 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 <patchbot> https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets
21:05:04 <timburke> 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 <clayg> yeah, i agree lp bug #1860149 is pretty awful
21:06:14 <alecuyer> ouch
21:06:26 <timburke> 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 <clayg> 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 <patchbot> https://review.opendev.org/#/c/702950/ - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets
21:06:32 <kota_> i'll be back to https://review.opendev.org/#/c/702950/
21:06:33 <patchbot> patch 702950 - swift - Allow Timestamp comparisons against out-of-range v... - 2 patch sets
21:07:50 <timburke> thanks clayg and kota_! your input will be invaluable, i'm sure :-)
21:07:59 <timburke> #topic versioning
21:08:47 <timburke> 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 <clayg> 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 <kota_> either is fine to me, any tagged point will be acceptable from my org.
21:12:46 <alecuyer> waiting until the patches you mentionned are in sounds reasonnable
21:13:08 <timburke> 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 <clayg> timburke: mostly *yours* but... also it'd be nice to have sweet shiny changelog!
21:14:17 <timburke> hell yeah it would be!
21:14:23 <timburke> 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 <patchbot> https://review.opendev.org/#/c/682382/ - swift - New Object Versioning mode - 74 patch sets
21:14:26 <patchbot> https://review.opendev.org/#/c/698139/ - swift - Skip container-sync when versioning enabled - 14 patch sets
21:14:34 <clayg> 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 <rledisez> 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 <rledisez> *the big thing
21:15:11 <timburke> Freudian slip ;-)
21:15:13 <rledisez> so i guess both options are fine for me
21:16:14 <kota_> 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 <timburke> 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 <clayg> 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 <rledisez> 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 <tdasilva> 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 <clayg> oh no!  bummer...
21:19:23 <clayg> 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 <tdasilva> clayg: +1
21:20:13 <timburke> 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 <tdasilva> i think it would be nice to fix that
21:20:38 <timburke> so, before or after a merge? ;-)
21:20:50 <tdasilva> heh, that's the question!
21:21:00 <clayg> ahahah, if it's a bug we can demonstrate it should be before!
21:21:11 <tdasilva> i'd say, let's mere as is, and follow-up patch before release
21:21:25 <clayg> 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 <mattoliverau> 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 <mattoliverau> 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 <clayg> 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 <tdasilva> mattoliverau: currently no, and that's what needs to be fixed
21:22:56 <clayg> mattoliverau: no, i agree - most likly this out of sync conditions are temporary
21:23:09 <tdasilva> clayg: I'm just trying to avoid we get to 100 patchset mark :D
21:23:17 <mattoliverau> lol
21:23:40 <clayg> 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 <timburke> tdasilva, that's still like 25, 26 away! lot's of time :P
21:23:50 <clayg> tdasilva: LOL
21:24:22 <clayg> tdasilva: i can really HEAR your voice in my head when you say that!!!  😍
21:25:11 <clayg> timburke: tdasilva: was that the only issue?
21:25:29 <clayg> 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 <tdasilva> that we know of :/
21:26:08 <clayg> 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 <clayg> I was ready to merge it last week and I'm sure it's only gotten better 👍
21:26:23 <timburke> 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 <clayg> 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 <timburke> eh, i'd be fine with fixing up listings in follow-ups
21:28:14 <timburke> on the s3 patch 673682 though... i've got a few more worries
21:28:14 <patchbot> https://review.opendev.org/#/c/673682/ - swift - s3api: Implement object versioning API - 45 patch sets
21:28:27 <timburke> i need to get more of that loaded into my head i think
21:28:42 <clayg> oh, ok then!
21:30:50 <timburke> 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 <clayg> timburke: yeah that's find - do you want to merge versoining; then tag; then probably merge s3api support after that?
21:32:06 <timburke> clayg, that's one of the things i'm debating about
21:32:39 <tdasilva> won't help with release notes tho
21:32:45 <timburke> honestly, i'm not sure
21:33:02 <clayg> 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 <clayg> or... just a bunch of review comments somewhere between patch #10-#86?
21:33:20 <patchbot> No data found for patch 10
21:33:22 <timburke> maybe i should just push up my edits to the s3 patch and let it go in, too
21:33:43 <clayg> well, you should definately push up your edits :D
21:34:09 <timburke> clayg, enable versioning on a container, then use an internal client or something to go delete the versions container
21:35:48 <timburke> 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 <timburke> all right, sounds like we've got something of a plan for how what to do next on versioning...
21:36:57 <timburke> #topic open discussion
21:37:08 <timburke> does anyone have anything else they'd like to bring up?
21:40:23 <timburke> all right, then
21:40:34 <timburke> thank you all for coming, and thank you for working on swift!
21:40:40 <timburke> #endmeeting