21:00:33 <notmyname> #startmeeting swift
21:00:34 <openstack> Meeting started Wed Oct  4 21:00:33 2017 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:38 <openstack> The meeting name has been set to 'swift'
21:00:38 <notmyname> who's here for the swift meeting?
21:00:43 <m_kazuhiro> o/
21:00:58 <mattoliverau> o/
21:01:00 <timburke> o/
21:01:14 <kota_> hello
21:01:19 <rledisez> hi o/
21:02:11 <notmyname> waiting for a couple of more people (hopefully)
21:02:42 <notmyname> agenda is at
21:02:44 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:06 <jungleboyj> o?
21:03:08 <jungleboyj> @!
21:03:08 <_pewp_> jungleboyj (。･д･)ﾉﾞ
21:03:37 <notmyname> hmm... I thought clayg and torgomatic would be here
21:03:45 <notmyname> and acoles
21:04:24 <notmyname> there's acoles!
21:04:33 <acoles> hey! sorry I am late
21:04:33 <notmyname> the 0700 meeting notes are at
21:04:35 <notmyname> #link http://eavesdrop.openstack.org/meetings/swift/2017/swift.2017-10-04-07.01.log.html
21:04:57 <notmyname> ok... let's get started
21:05:02 <notmyname> there's a few things to go over
21:05:26 <notmyname> without spending time discussing it in here, please continue to triage bugs
21:05:28 <notmyname> #link https://etherpad.openstack.org/p/swift-bug-triage-list
21:05:41 <notmyname> the list is getting shorter :-)
21:05:51 <notmyname> #topic s3api status
21:06:04 <notmyname> I'd like to briefly get an update on swift3 and the s3api feature branch
21:06:08 <notmyname> ( kota_ )
21:06:09 <kota_> yup
21:06:38 <notmyname> my understanding is that you were planning for a swift3 release sometime soon, right?
21:06:52 <notmyname> and after than, a migration patch would land on the s3api branhc?
21:06:57 <kota_> I reviewed 4 patches on the top of https://etherpad.openstack.org/p/s3api-middleware
21:07:00 <notmyname> where are we with those items?
21:07:44 <kota_> I'd like to get in https://review.openstack.org/#/c/331291/ to the release, others don't have to be in.
21:07:44 <patchbot> patch 331291 - swift3 - Don't try to read a body if the client didn't send...
21:07:59 <kota_> (nice to have, though)
21:08:28 <kota_> timburke: here?
21:08:36 <timburke> and i need to go address some of those review comments...
21:08:46 <notmyname> ok
21:08:48 <kota_> thanks timburke
21:08:50 <clayg> oh, this...
21:08:52 <clayg> what'd I miss?
21:09:03 <kota_> and also i'd like to get timburke's comments for https://review.openstack.org/#/c/504479/
21:09:04 <patchbot> patch 504479 - swift3 - Change log updates for version 1.12
21:09:04 <notmyname> clayg: talking about s3api
21:09:32 <kota_> that's the final pieces for the release
21:09:37 <notmyname> kota_: do you think the plan is still good? release swift3, put code ont eh s3api feature branch, make the non-compat changes we want, then merge s3api to master
21:09:52 <kota_> after the release, I'll prepare the migration to the feature branch
21:10:07 <kota_> yup
21:10:12 <notmyname> great
21:10:23 <notmyname> any questions from anyone else about this process or what's going on?
21:10:37 <clayg> notmyname: timburke just fixed a really sneaky coupling issue with swift3 and swift that really would have benifited (and maybe even been avoided!?) with s3 api compat *in-tree* (patch 509594)
21:10:39 <kota_> I'm thinking swift3 will be in soft-freeze mode while migration time.
21:10:57 <notmyname> kota_: makes sense
21:11:12 <notmyname> patch 509594
21:11:13 <patchbot> https://review.openstack.org/#/c/509594/ - swift - Stop clearing params for account_autocreate responses
21:11:22 <torgomatic> whoops, sorry I'm late
21:11:29 <notmyname> ah, right. he mentioned it
21:11:33 <clayg> so I'd just like to point how what a great idea this is, and how kota_ and timburke are awesome and we welcome their new dictatorship over all things s3 api compat
21:11:37 <notmyname> and yep. I'm excited about having it in tree
21:11:41 <notmyname> heh
21:11:53 <kota_> timburke: how do you think of brand-new patches for swift3? I saw a few patches you pushed in this week?
21:11:58 <notmyname> the "read between the lines" part is "don't ask clayg about s3 compat" ? ;-)
21:12:12 <clayg> baby steps
21:13:13 <timburke> kota_: i'm fine with it for upstream i suppose. but i also know that i'll more than likely have to do my own release for my company before the migration is done
21:13:22 <notmyname> it's also important to note that we shouldn't freeze swift3 and then never merge down the s3api feature branch. that would be bad
21:13:50 <notmyname> (meaning whip-cracking and encouragement to help out, when we get to that point)
21:14:03 <timburke> indeed it would. my releases would jsut continue to diverge and no one would be happy :P
21:14:13 <notmyname> we don't want people to be sad
21:14:20 <kota_> alright
21:14:30 <notmyname> kota_: you good? anything else to bring up on this topic?
21:14:53 <kota_> depends on the number of patches and size
21:15:04 <kota_> their size
21:15:40 <notmyname> #topic container sharding
21:15:57 <notmyname> acoles: timburke: mattoliverau: what's the update on feature/deep?
21:16:09 <notmyname> where do we stand? is the plan working? what do you need?
21:16:36 <acoles> IMHO we're making good progress, particularly adding test coverage
21:16:41 <mattoliverau> so far the plan is going great guns. timburke  and acoles have done awesome
21:16:52 <acoles> e.g. timburke has given us some probe tests
21:17:02 <acoles> feature/deep is a great place to be hanging out
21:17:21 <acoles> we need more timburke's
21:17:22 <acoles> :)
21:17:23 <timburke> stuff moves so fast! at least, when the gat's not busted ;-)
21:17:29 <notmyname> heh
21:17:31 <timburke> gate*
21:17:35 <acoles> oh yeah and a working gate
21:17:47 <mattoliverau> Done some really great cleanup, code is much cleaner.
21:17:55 <notmyname> hmm... swift is used to store genomes. wonder if we can clone timburke. in lieu of that, what do you need?
21:18:06 <mattoliverau> Tests coverage it covering and uncovered some interesting edge cases
21:18:24 <clayg> i love it when writing tests finds bugs!  feels *so* good!
21:18:27 <acoles> notmyname: we've been working through some of the functional elements, cleaning up and adding tests, flushing out bugs and
21:18:40 <acoles> oh that all got said... thanks mattoliverau
21:18:46 <mattoliverau> Lol
21:19:05 <notmyname> #link https://trello.com/b/z6oKKI4Q/container-sharding
21:19:13 <notmyname> *lots* of stories there
21:19:48 <acoles> if anyone wants to get involved there are some easy tasks to pick up on trello, particularly if you don't mind writing unit tests ... and who doesn't ;)
21:20:12 <notmyname> acoles: how would one find those on trello?
21:20:52 <acoles> umm, search for unit test in the Backlog column, or ask me
21:21:11 <acoles> notmyname: (I know, a better answer would be 'low hanging fruit tag')
21:21:40 <notmyname> ok :-)
21:22:01 <notmyname> anything else to bring up or discuss in the meeting related to container sharding?
21:22:15 <mattoliverau> We also have a questions column so if something arises or something is not understand feel free to ask there
21:22:29 <mattoliverau> Understood..
21:22:50 <mattoliverau> Apparently English is my native language and I still can't English
21:23:02 * notmyname waits for the acoles comment...
21:23:14 <acoles> que?
21:23:18 <notmyname> #topic undeletes! (the best kind of deletes)
21:23:29 <notmyname> #link https://review.openstack.org/#/c/507808/
21:23:30 <patchbot> patch 507808 - swift - Add ability to undelete an account.
21:23:38 <notmyname> this patch has been up for a while
21:23:50 <notmyname> (looks like the author is someone on a team using a common email?)
21:23:59 <clayg> oh, rledisez looked at it!? that's... *amazing*
21:24:17 <notmyname> but it's a totally great feature that swift has never actually implemented despite having "someday we'll do this..." in our docs for 7+ years
21:24:27 <clayg> yeah it's weird they're doing that?  it really depersonalizes it for me..
21:25:01 <notmyname> oh, the "owner"?
21:25:33 <clayg> notmyname: yeah i'd really like to engage and be like "we haven't been putting this off because we're lazy, it's like acctually sorta non-trivial as I'm sure you know from having to write a patch spanning 4 different modules ..."
21:25:46 <notmyname> does anyone know who the actual author is? even better, their irc nick?
21:26:41 <acoles> the patch looks very similar to https://review.openstack.org/#/c/445160 so I am interested to know if it the same author
21:26:42 <patchbot> patch 445160 - swift - Un-delete accounts that were previously marked as ...
21:26:49 <clayg> I mean... there's not enough tests - the whole thing could probably *really* use a probe test - if we start reviewing this stuff will come up - we'll either have to fix it and push back - and if we push back they'll need to know it's all with love
21:27:08 <clayg> notmyname: here here!  we need to get them on irc?
21:27:18 <notmyname> their website says, "Who are we? A global conglomerate--adding value to people's lives". so that's not super helpful
21:27:31 <acoles> oxymoron
21:27:37 <clayg> rofl
21:27:42 <rledisez> it may be not the same author, but the current patch seems at least inspired by the previous patch and its comments
21:27:58 <notmyname> ok, I'll leave a note in gerrit asking for them to identify themselves on irc if possible
21:28:03 <clayg> ok, so maybe this isn't "the moment" - but that's sad because yeah, it'd be great to have some help and this seems useful
21:28:19 <acoles> is Adam Thurlow ... thurloat maybe? looks like it
21:28:21 <notmyname> rledisez: seems that you most recently looked at it... is there something specific we need to do or encourange them to do? what will it take to merge it?
21:28:26 <notmyname> acoles: yes
21:28:55 <acoles> I wonder if we should be reviewing the original patch?
21:29:02 <rledisez> notmyname: to me, it looks quite good and simple. i'm concerned by unattended behavior for users, so i think some point need to be claried on the "workflow"
21:29:08 <rledisez> when can i undeleted, when can't i, ...
21:29:25 <notmyname> rledisez: docs concerns? or actual design concerns?
21:29:45 <rledisez> design concerns for now. like you can undeleted an account that is currently being reaped. don't look good to me
21:29:45 <mattoliverau> And Donagh reviewed it too
21:30:10 <notmyname> yeah. the fact that both donagh and rledisez looked at it is fantastic :-)
21:30:21 <mattoliverau> +100
21:30:54 <notmyname> clayg: you brought up this patch (thanks!). is there something else specifically you wanted to address on it, other that what we just did?
21:31:32 <clayg> i think we're good
21:31:40 <notmyname> kk
21:31:48 <notmyname> #topic PUT+POST^N
21:31:54 <notmyname> #link https://review.openstack.org/#/c/427911/
21:31:55 <clayg> there's a meta discussion about bring new people "into the fold" - but it's probably all depending on the situation
21:31:55 <patchbot> patch 427911 - swift - PUT+POST and its development test
21:32:03 <notmyname> pete's patch that unblocks the future
21:32:13 <notmyname> ...and he's not in here
21:32:26 <clayg> I guess on this one I had *intended* to maybe glance at it before today incase I had any high level questions for zaitcev
21:32:31 <clayg> but yeah... guess that doesn't matter
21:32:43 <clayg> so last bit of info was I plan to look at it soonish (friday?)
21:33:02 <clayg> torgomatic: are you talking to zaitcev about this patch?  something with keeping diskfilewriter around?
21:33:10 <clayg> is there a pre-req patch I should review instead?
21:33:13 <notmyname> as a reminder, this patch restores "real" http to the proxy<->object protocol, and that will unblock us from moving forward with various plans to remove eventlet from the object server
21:33:20 <torgomatic> clayg: I sent him a link to some stuff I wrote, but that's about all I've got time for today :(
21:33:33 <clayg> i'm interested in this body of work - decoupling ourselves from eventlet in the object server so *so* key
21:33:48 <clayg> cc rledisez ya boy needs this patch too
21:34:14 <rledisez> clayg: totally!
21:36:02 <notmyname> aside from clayg giving it a review and torgomatic chatting in IRC as he's able, what else needs to be done on this patch?
21:37:34 <clayg> i that's it for that one - well - we probably need one more person to be thinking they're going to review/understand the protocol change along the way at the end
21:37:51 * notmyname nods vigorously
21:38:28 <clayg> but that could mostly be torgomatic and I - I think tdasilva timburke and obviously zaitcev also have a good understand
21:38:32 <clayg> notmyname: you too
21:38:41 <clayg> so ... yeah - good for now!
21:38:47 <notmyname> drat! you've caught me!
21:38:51 <clayg> unless torgomatic and I drop the ball (more likely for me than him)
21:39:04 * mattoliverau would love to commit, but first need to convince $employer to let me spend more time on Swift.
21:39:14 <notmyname> #topic open discussion
21:39:16 <rledisez> it seems to me there's a lot of thing in that patch that is not directly related to PUT+POST (eg: https://review.openstack.org/#/c/427911/19/swift/common/wsgi.py ). is it on purpose?
21:39:17 <patchbot> patch 427911 - swift - PUT+POST and its development test
21:39:20 <notmyname> what else to bring up this week?
21:41:04 <timburke> https://review.openstack.org/#/c/509306/ adds a heartbeating mechanism to SLO that should let us get up towards S3's 10k part limit
21:41:05 <patchbot> patch 509306 - swift - Let clients request heartbeats during SLO PUTs
21:41:15 <notmyname> ah yes. thanks timburke
21:41:44 <mattoliverau> timburke: cool
21:41:47 <notmyname> yeah, that patch is significant because it lets a client opt in (right?) to a protocol change
21:42:10 <clayg> rledisez: I guess step 1 would be to rip it out and see if tests still pass... step 2 would be to split it out or clean it up...
21:42:11 <timburke> yup, client has to include a &heartbeat=on query param
21:42:16 <notmyname> FWIW, it works the same way as swift's bulk upload and s3's multipart complete
21:43:08 <kota_> it sounds like similar with bulk delete?
21:43:32 <timburke> yep. and bulk extract. and slo delete with ?multipart-manifest=delete
21:44:01 <rledisez> timburke: the same on copy for big objects would be useful also.
21:44:05 <clayg> @timburke i thought I read something in the commit message about some sort of 10 second timeout or something?
21:44:26 <clayg> does the client behavior *differ* depending on how slow the cluster is - or *only* depending on the request?
21:44:53 <clayg> like does heatbeat=on always yield the same status code - or it makes the status code variable depending on external factors?
21:45:33 <timburke> at the moment, it depends on both. but a client needs to be able to eat early errors regardless, so a quick response vs a slow response seems not-unreasonable
21:46:41 <clayg> so client facing heartbeat=on docs - they say "if you include this param you might get a 2XX that means success or you might get a 2XX that means we're working on it"
21:47:16 <notmyname> that's how it was explained to me
21:47:32 <timburke> pretty sure i included the docs change. but yeah, 201 == success, 202 == working, read the body to know whether it was successful or not
21:48:36 <notmyname> apologies, but I've got an unexpected personal obligation thats' come up  .... any last things to bring up in the meeting?
21:48:44 <timburke> bah, my docs change makes it sound like we always send the 202. should fix that
21:49:44 <notmyname> thank you for your awesome work on s3api, deep containers, and making swift generally better
21:49:48 <notmyname> #endmeeting