21:00:16 <notmyname> #startmeeting swift
21:00:17 <openstack> Meeting started Wed Oct 18 21:00:16 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:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:20 <openstack> The meeting name has been set to 'swift'
21:00:22 <notmyname> who's here for the swift team meeting?
21:00:22 <jungleboyj> o/
21:00:26 <timburke> o/
21:00:28 <torgomatic> 🌯
21:00:31 <m_kazuhiro> o/
21:00:31 <mattoliverau> o/
21:00:36 <rledisez> o/
21:00:37 <jungleboyj> At least for the first little bit.
21:00:40 <kota_> hi
21:00:45 <acoles> hi
21:01:06 <tdasilva> hi
21:01:08 <timburke> torgomatic: is that a... burrito?
21:01:25 <torgomatic> timburke: yep. burrito emoji is best emoji.
21:01:50 <notmyname> welcome to everyone, and torgomatic's burrito
21:01:54 <jungleboyj> Oh, that is what that is.  I thought it was like a dinosaur arm or something.
21:02:07 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:02:10 <notmyname> there's the agenda
21:02:30 <notmyname> note we didn't have an 0700 meeting (nothing was on the agenda, and no one brought up any topics)
21:02:57 <notmyname> #topic bug triage
21:03:06 <notmyname> let's go slightly out of order...
21:03:12 <notmyname> #link https://etherpad.openstack.org/p/swift-bug-triage-list
21:03:19 <notmyname> there's the bug triage etherpad
21:03:30 <notmyname> and tdasilva brough up the question of another bug triage day
21:03:36 <notmyname> tdasilva: any more to say on that?
21:03:54 <notmyname> #link https://bugs.not.mn/project/swift/bug_trends/None
21:03:57 <tdasilva> not really..was just wondering if we shoud do it again or not...
21:04:44 <notmyname> everyone, please share your thoughts
21:04:54 <notmyname> seems like a good idea to me
21:05:01 <mattoliverau> I'm up for it
21:05:19 <mattoliverau> Can't believe it's been a month already!
21:05:39 <timburke> yeah, probably would be good
21:06:08 <notmyname> IMO the main "good" of it is to have the designated time for it
21:06:25 <torgomatic> just be careful that our outgoing bugs don't stay above our incoming bugs for too long, or we'll have to borrow bugs to make ends meet
21:07:03 <notmyname> if you need more bugs, I can get back to writing some patches...
21:07:25 <mattoliverau> torgomatic: lol that's the idea :p
21:07:35 <jungleboyj> Cinder has plenty of bugs ... we will share.
21:07:48 <mattoliverau> lol
21:07:59 <notmyname> so when do we do it? next week? in two weeks ont he 1st?
21:08:34 <notmyname> any strong preferences?
21:08:50 <mattoliverau> I don't mind, either works.. tho the 1st does sound cool
21:09:19 <mattoliverau> And just before the summit, for those gojnf
21:09:27 <mattoliverau> Going even
21:09:57 <mattoliverau> ^come on auto correction, can you guess what I'm saying this early :p
21:09:58 <notmyname> also has the advantage of being the next scheduled 0700 meeting day
21:10:28 <notmyname> any opposition to setting a bug triage day to two weeks from today?
21:10:44 <mattoliverau> Of no one else has other strong opinions, let's do the 1st.. sold
21:11:13 <notmyname> ok, two weeks from now it is
21:11:24 <notmyname> bug triage day scheduled!
21:11:26 <kota_> wfm
21:11:32 * acoles adds it to calendar
21:11:34 <notmyname> #topic new release
21:11:34 <clayg> I somehow managed to not much do bug triage on bug triage day last time
21:11:45 <clayg> ... it mostly had to do with that day being already booked with meetings
21:11:57 <notmyname> do we need a new swift release soon?
21:11:59 <clayg> ... and I can't just NOT do any coding ...
21:12:18 <mattoliverau> clayg:  and the next bug triage day? You have 2 weeks to book it up again ;)
21:12:35 <notmyname> I'm inclined to say yes we should cut a release. there's some good stuff there, and it's been about 2 months since the last one
21:12:35 <clayg> well - is it on a wednesday?  I think I missed the decision/date?
21:12:35 <timburke> notmyname: we *always* need a new release. it just keeps getting better!
21:12:42 <notmyname> timburke: right on!
21:12:46 <clayg> timburke: +2
21:12:49 <tdasilva> notmyname: this week is Quest M1, correct?
21:12:52 <notmyname> clayg: two weeks from today
21:13:05 <clayg> tdasilva: +2 where are we at on openstack release-y bits?
21:13:18 <notmyname> I don't think that's mattered before, has it?
21:13:19 <clayg> so it *is* on a wednesday :'(
21:13:35 <notmyname> clayg: you can do it on a tuesday if you want :-)
21:13:39 <clayg> notmyname: not the specific date - but we're going to want to do a release for Q
21:13:47 <tdasilva> notmyname: no, just a good coincidence for the downstream testers that do care about it thou...
21:13:49 <clayg> notmyname: that's a good idea!  I'll try that
21:14:20 <tdasilva> lol, not Quest, Queens!
21:14:22 <notmyname> right. aside from the end-of-cycle release, the openstack milestone dates don't stongly influence us
21:14:30 * notmyname likes Quest better ;-)
21:14:58 <mattoliverau> clay or you can be an honorary Australian and do it on Thursday, case 2 weeks from today is a Thursday here ;)
21:15:02 <clayg> maybe it just accident - but I always liked it when we do a "slight after the upstream with stuff we decided not to merge at the last minute for upstream" release - then something in the upstream RC phase as the "probably about what is going into the upstream release sans a few things that aren't quite polished/pushed" and then another one... FOR the upstream release
21:15:39 <clayg> that ends up ~5-6 releases a year, or one every other month-ish and that feels about right more or less
21:15:53 <notmyname> the upstream queens release isn't until late february or early march
21:16:10 <clayg> oh, so we're just late with our after pike release?
21:16:23 <clayg> was pike 2.15 or 2.14?
21:16:23 <notmyname> only "late" if you expected it earlier
21:16:31 <notmyname> pike was 2.15.1
21:16:37 <notmyname> that was our last release about 2 months ago
21:16:53 <notmyname> ok... let me start over and rephrase :-)
21:17:19 <notmyname> let's do a release soon! I'll set up the priority reviews page, and please make sure you tage any bugs as critical that should block a release
21:17:22 <notmyname> :-)
21:17:43 <notmyname> this will be for swift 2.16.0
21:17:47 <mattoliverau> notmyname: good idea, and thanks :)
21:17:59 <clayg> yeah so we're right on time?
21:18:27 <mattoliverau> Yup, it's the perfect time for release :)
21:18:35 <clayg> pike was August
21:18:39 <kota_> +1
21:18:51 <notmyname> https://wiki.openstack.org/wiki/Swift/version_map
21:18:57 <notmyname> pike was august 21
21:19:14 <notmyname> 2 months ago, almost to the day
21:19:53 <notmyname> I'll get working on the logistics for it
21:20:26 <notmyname> and I think this will be good, especially considering the feature branches currently in play. gives us a reasonable lead time for landing one or more before the next release (or openstack q)
21:20:32 <notmyname> speaking of...
21:20:41 <notmyname> #topic ongoing work checks
21:20:51 <notmyname> how's container sharding going this week?
21:21:14 <notmyname> I know acoles has made some good progress on shrinking
21:21:15 <clayg> notmyname: we should definitely release before landing some of the big feature branches
21:21:21 <clayg> maybe?
21:21:34 <notmyname> what else is going on? anything you need to bring up for discussion or that blocks anything?
21:21:42 <notmyname> #link https://trello.com/b/z6oKKI4Q/container-sharding
21:21:47 <mattoliverau> Yeah, acoles has been working more on a new and better shrinking alg
21:21:53 <acoles> I'm hopeful that the 'simpler' shrinking approach is going to do the job.
21:21:57 <clayg> notmyname: timburke has the SLO heartbeat change - I think that's a good 'en
21:22:00 <mattoliverau> And related probe tests
21:22:08 <clayg> oh... just on sharding - my bad
21:22:21 <acoles> found some systemic bugs last week that once fixed have got the shrink test passing
21:22:49 <mattoliverau> Not as much work this week unfortunately. But that's mostly me being busy
21:23:13 <mattoliverau> acoles is awesome
21:23:16 <acoles> this week I've been working on collating listings from multiple shards
21:23:29 <notmyname> mattoliverau: something blocking you that we can help with, or is it more on other $DAYJOB commitments?
21:23:38 <timburke> me too :-( i at least got my merge commit in last friday, but i haven't done my follow-up address-review-comments patch yet (iirc)
21:24:55 <mattoliverau> Yeah, $DAYJOB.. and not giving me as much time :( home life a little busy this week too
21:25:09 <notmyname> ok
21:25:34 <notmyname> sounds good. thanks for all your work on it this week
21:25:45 <notmyname> how about the s3api work?
21:25:54 <notmyname> kota_: and tdasilva have been doing a lot there, I've seen
21:26:19 <kota_> early of this week, swift3 got a new release
21:26:26 <notmyname> swift3 has had it's "final" tag
21:26:27 <notmyname> yay!
21:26:35 <kota_> and I'm starting to migrate the code to s3api feature branch
21:26:45 <notmyname> and the code was merged to the feature branch? or has it not landedyet?
21:26:49 <kota_> https://review.openstack.org/#/c/512284/
21:26:50 <patchbot> patch 512284 - swift (feature/s3api) - Import all swift3 code as s3api
21:27:20 <kota_> not yet, thought it's just a full copy though.
21:27:25 <tdasilva> kota_: I started moving some of the files around: https://review.openstack.org/#/c/513170/1
21:27:26 <patchbot> patch 513170 - swift (feature/s3api) - Continue merge swift3 middleware
21:27:32 <notmyname> note to everyone that we are *not* preserving the git history from the swift3 codebase into swift
21:27:46 <kota_> 1. tdasilva minds to save git history....
21:28:20 <kota_> tdasilva: great
21:28:35 <kota_> oh, yeah,
21:28:58 <kota_> notmyname: thanks for covering the issue for notification to all
21:29:21 <kota_> done for the 1, above.
21:29:26 <notmyname> any question on this? anything from kota_ or tdasilva for questions for the group?
21:29:48 <timburke> note that when we do the final merge, it'd probably be nice to have one commit that is a straight copy, with follow-on commits to move things into position
21:30:08 <tdasilva> timburke: that's what I was planning to
21:30:16 <timburke> perfect :-)
21:30:27 <tdasilva> timburke: kota's patch does that with some very minor changes
21:30:44 <tdasilva> and then my follow-on patch starts moving things around
21:31:02 <kota_> yup
21:31:45 <tdasilva> kota_: maybe we can continue some planning after this meeting on #openstack-swift channel?
21:31:48 <clayg> what is the burndown list for merge to master?  Are we still defining that scope or do we have a pretty clear picture?
21:31:59 <kota_> tdasilva: sure
21:32:16 <notmyname> clayg: excellent question
21:32:20 <clayg> is there anything that looks like a "beta" - since for awhile going with the last commit to swift3 is probably a better option for new deployments than trying out s3api to figure out what we missed?
21:32:25 <notmyname> I have a general idea of the merge to master stuff
21:32:36 <tdasilva> clayg: we started writing down some tasks on an etherpad, but I was thinking it would be nice to have a trello board like sharding....
21:32:50 <notmyname> remove some of the s3_acls configs and redo how the bucket is mapped to (account, continaer)
21:32:57 <notmyname> tdasilva: +1
21:33:21 <clayg> like torgomatic was talking bucket registries - I sure wouldn't want to see us starting this process if we're holding on that - but if stuff is going to "change wildy in backwards incompatible ways" after the merge we need to have something that steers people away from building on this new hawtness until we're ready to support it
21:34:00 <tdasilva> https://etherpad.openstack.org/p/s3api-middleware
21:34:09 <torgomatic> yep, I'd hate to have something on master that we then break compatibility with, because then we've either got to figure an upgrade path or deal with angry users
21:34:54 <clayg> tdasilva: notmyname: to me that sounds like we're still defining scope ... but idk ... maybe we can get it "all" done w/o having massive pressure to continue to make (perhaps minor) improvements to swift3
21:35:15 <notmyname> kota_: tdasilva: can I set up a trello board for the eventual merge to master?
21:35:36 <tdasilva> notmyname: sure, +1
21:35:39 <clayg> torgomatic: i'm on with it "on master" and having integration testing hawtness going *while* we break it (personally)
21:35:44 <kota_> sounds good.
21:35:48 <clayg> but we'd have to make it like idk, BETA or something
21:35:51 <notmyname> clayg: yeah, your concern is that we'll have to keep updating swift3 while we're working on big s3api stuff before a merge to master?
21:36:04 <torgomatic> clayg: as long as we've got enough barriers that people don't accidentally start using it, that 's probably fine
21:36:24 <clayg> notmyname: well I saw us celebrate "we're done with swift3" and that means either we're close to a merge of s3api to mater or we're liars ;)
21:37:06 <clayg> torgomatic: the point where people can start using it is when we get to stop working on swift3?
21:37:22 <tdasilva> clayg: I think 'we're done with swift3' meant more as in: 'soft freeze, swift3 won't get more big ticket features'
21:37:25 <clayg> i could be wrong about that point too... if the runway is short enough we can tell people to hold their breath
21:37:26 <timburke> yeah, we're liars. i'm about to do some manual testing on my own 1.12.0.1, and i already see some of what 1.12.0.2 will need
21:38:04 <clayg> or we can "work" on swift3 but not like "massive" efforts - just like small improvements and stuff that looks more like bug fixes (which I think kota & tim were planning on doing anyway)
21:38:06 <timburke> not that i think a soft freeze on swift3 was a bad move -- i just need to keep customers happy
21:38:26 <clayg> ok yeah soft freeze - i love it
21:38:34 <tdasilva> timburke: right...maintenance mode??
21:38:36 <notmyname> I'll get a trello baord updated with that so we can see what's left and how much we're liars or how close we are :-)
21:38:50 <clayg> the idea is "don't go redesigning on implementing huge things in swift3 that's not where it's at; we could use help over here where it's at"
21:39:03 <tdasilva> clayg: +1
21:39:15 <clayg> timburke: thanks for the clarity
21:39:34 <notmyname> ok, next up..
21:39:40 <clayg> notmyname: i might have to pick one of these feature branches to start paying attention to :\
21:39:48 <timburke> i don't know that i added any clarity, but w/e...
21:39:54 <notmyname> clayg: no problem :-)
21:40:04 <notmyname> m_kazuhiro: kota_: I've seen a lot of discussion this week on symlinks
21:40:07 <notmyname> what's going on?
21:40:19 <clayg> timburke: probably i was just confused - you do good speaking clearly - so when you talk it tends to clear things up for me ;)
21:40:35 <m_kazuhiro> Please wait a little....
21:40:44 <clayg> symlinks!
21:40:58 <kota_> i thought m_kazuhiro got conclusions on some remaining issues.
21:40:58 <clayg> we're gunna post to them and then 307 - it's amazing
21:41:09 <notmyname> m_kazuhiro: you want me to come back to this topic?
21:41:46 <m_kazuhiro> notmyname: If I can, it is good for me.
21:41:53 <notmyname> ok
21:42:16 <notmyname> clayg: any updates for the big "remove eventlet" work?
21:42:25 <notmyname> anything on pete's patch or tsync or anything?
21:43:12 <clayg> pete is going to do another rev - it's going to be great
21:43:27 <clayg> next thing from me on replication will be for priority db replicators
21:43:48 <clayg> I think after that I'm probably mostly interested in worker pattern expansion beyond reconstructor
21:44:09 <notmyname> this is getting the goodness we've got in the object replicators into the DB replicators?
21:44:22 <timburke> fwiw, we already see how that'd be nice to have on feature/deep :-)
21:44:35 <notmyname> oh, yeah, that makes sense :-)
21:44:40 <clayg> i'm not sure when we're going to work on fixing the REPLICATE api rehash on-disk protoc stuff
21:45:11 <notmyname> clayg: is there anything you need from the rest of us?
21:45:43 <clayg> i mean not unless someone has some cycles and really cares about reducing bullshit iops on object devices
21:46:33 <clayg> i'm still in squeeze what we can out of what we have mode - but "somewhere" down the road i also have opinions about a better world...
21:46:33 <notmyname> rledisez: what's up with LOSF work?
21:46:45 <notmyname> clayg: :-)
21:47:01 <rledisez> not much. alecuyer's been working on finding that bug
21:47:11 <rledisez> a bit tricky, but he's on the right track
21:47:32 <rledisez> i hope better news next week
21:47:46 <notmyname> ok
21:47:55 <notmyname> m_kazuhiro: are you ready?
21:48:04 <m_kazuhiro> notmyname: OK
21:48:18 <notmyname> #link https://etherpad.openstack.org/p/swift_symlink_remaining_discussion_points
21:48:18 <m_kazuhiro> We got conclusions for some of remaining discussion points. Then, our remaining discussion points are only 2. And I’m updating symlink patch for review comments.
21:48:39 <notmyname> great
21:48:55 <notmyname> when do you expect to have it in gerrit ready for comments?
21:50:08 <m_kazuhiro> Last of next week of early of next next week. In my current plan.
21:50:22 <notmyname> ok, thank
21:50:27 <notmyname> #topic open discussion
21:50:40 <notmyname> we have a few minutes left. anything that needs to be brought up by anyone?
21:50:52 <notmyname> oh! clayg you mentioned the slow-SLO patch
21:51:12 <timburke> slow slow slow
21:51:12 <notmyname> actually that's timburke's
21:51:24 <clayg> well of *course* it's timburke's!?
21:51:25 <mattoliverau> Lol slow slow patch :)
21:51:50 <timburke> https://review.openstack.org/509306
21:51:51 <patchbot> patch 509306 - swift - Let clients request heartbeats during SLO PUTs
21:52:12 <clayg> @timburke you gunna fix the xml thing?  with the <delete> in the response?
21:52:40 <clayg> regardless I think it's a great idea and seems to WOMM
21:52:49 <clayg> coverage/docs looks good
21:52:50 <timburke> idk... i'd intentionally *not* called out support for xml responses, even though i knew it was available
21:52:56 <clayg> I think it's pretty mergable
21:53:17 <clayg> oh but the docs *do* call out xml?
21:53:28 <timburke> maybe better for me to just rip that part out
21:53:52 <clayg> i guess - except we *do* response xml - but then the xml response is acctually for a bulk delete :\
21:54:10 <clayg> oh - you mean just like don't respond xml!?
21:54:15 <clayg> that plan I love 100% +#
21:54:35 <clayg> #xmlwhatwhonow
21:54:54 <notmyname> clayg: so we can rip out xml but we can't have this opt-out because that could break clients? ;-)
21:56:12 <clayg> notmyname: I think that's false equivalence - but i'm acctually open to any discussion on what needs to be done to get this patch mergable
21:56:19 <notmyname> I mean, a reasonable position is to rip out xml support when the client does opt-in, so that's a little bit of a joke :-)
21:56:24 <notmyname> clayg: WINKY FACE!
21:56:25 <clayg> i'm mostly interested in getting the heartbeat api released - so...
21:57:12 <notmyname> yeah, it's a Good Thing to have
21:57:14 <clayg> notmyname: yeah yeah - i'm not complaining!  false equivalence is great technique to setup an argument!  attack from a defensible posistion!
21:58:08 <notmyname> anyway... let's keep talking about XML responses to slow-SLOs in -swift and gerrit. and let's get this merged ASAP :-)
21:58:45 <notmyname> there's lot's going on. I don't know why I expect anything different, but wow. thank you, everyone, for your work to make swift awesome(r)!
21:59:06 <clayg> +2 get merged!  timburke let us know if we can help - you can't fix all the things (s3api, deep, slo)... acctually who am I kidding - this is timburke we're talking about - carry on
21:59:07 <notmyname> thanks for coming today
21:59:15 <notmyname> #endmeeting