21:01:49 <timburke_> #startmeeting swift
21:01:50 <openstack> Meeting started Wed Jun  5 21:01:49 2019 UTC and is due to finish in 60 minutes.  The chair is timburke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:53 <openstack> The meeting name has been set to 'swift'
21:02:02 <timburke_> who's here for the swift meeting?
21:02:03 <kota_> hello
21:02:08 <notmyname> o/
21:02:13 <tdasilva> hi
21:02:43 <mattoliverau> o/
21:02:58 <rledisez> o/
21:03:42 <clayg> o/
21:03:57 <timburke_> i forgot the update the agenda to reflect the actual state of what we need to discuss, but the broad topics are right
21:04:03 <timburke_> #agenda https://wiki.openstack.org/wiki/Meetings/Swift
21:04:13 <timburke_> #topic migration to story board
21:04:26 <timburke_> who's had a chance to play around in the storyboard sandbox?
21:04:41 <timburke_> #link https://storyboard-dev.openstack.org/#!/project/openstack/swift
21:04:56 <mattoliverau> Opps, I was meaning to play with the sandbox.. but didn't.
21:05:27 * diablo_rojo lurks
21:05:48 <mattoliverau> Opps did I just say that out loud :p
21:06:19 <timburke_> diablo_rojo, well, i've got some feedback :-)
21:06:37 <timburke_> responsiveness is a bit of a problem. 10-12s to load a story and 14-15s to load the first 10 active stories for a project? launchpad has its own issues, but i don't recall it being *this* bad
21:07:06 <timburke_> being able to have **bold**, *italics*, and `code` is nice. i can especially see the ability to have code blocks being good for tracebacks and curl output, for instance
21:07:19 <diablo_rojo> timburke_, we set up a slow log query and are starting to look over it to make improvements on loading times
21:07:35 <timburke_> (iirc, launchpad would lose all the indents for tracebacks)
21:07:36 <diablo_rojo> and by 'we' I mean corvus :) Thanks corvus :)
21:07:52 <timburke_> applying styling to migrated stories is an interesting choice -- i maybe would've put everything in code blocks to preserve the monospaced formatting that launchpad does (again, thinking about tracebacks and sample output), but i could see arguments either way
21:08:03 <timburke_> being able to get to a project's resolved stories quickly is good. finding a related (but closed) issue is definitely one of the more annoying things about launchpad IMO
21:08:17 <timburke_> search field could use some help text; what operators do i get? how do i combine them? as a result, finding all stories that i'm subscribed to (for example) is not obvious
21:08:30 <timburke_> on the stories search, it's not clear what projects are in play for a given story; i have to click through to the story, which is worsened by the responsiveness problems
21:08:46 <timburke_> would be nice if i could specify a default set of filters when i go to the story list; "all open stories, across all projects, sorted by most-recently updated" is unlikely to be right for anyone
21:08:59 <timburke_> sorry, that was a bunch all at once :-)
21:09:10 <diablo_rojo> timburke_, you can set up an automatic worklist with those default filter criteria
21:09:19 <diablo_rojo> timburke_, happy to have feedback :)
21:09:53 <timburke_> cool! i hadn't gotten around to messing with worklists -- i just knew that i wanted to go looking for some stories, so i clicked on "stories" :-)
21:10:22 <diablo_rojo> If its a common set of criteria you will go back to repeatedly I would make a worklist
21:10:27 <diablo_rojo> an automatic one
21:11:56 <timburke_> for me, the two biggest things would be "open stories for these projects" and "stories i'm subscribed to"
21:12:13 <tdasilva> is a worklist a global/public list or owned/visible by user?
21:12:45 <timburke_> with the latter maybe getting split into "in this set of projects that i have a lot of interest in" and "outside of that set"
21:12:56 <diablo_rojo> they are public but they are owned by the person that creates them. Other can subscribe to them but I think you need to add people to them if they are going to make changes to the worklist.
21:13:19 <diablo_rojo> If there are private things in the worklist, sb is smart and wont show the user if they dont have the correct permissions
21:13:44 <timburke_> "stories/tasks assigned to me" might also be useful, but i feel like at that point i'm more likely to be thinking in terms of reviews and looking to gerrit instead
21:13:59 <diablo_rojo> timburke_, you should be able to see that on your dashboard
21:14:08 <timburke_> makes sense
21:14:17 <mattoliverau> Interestingly we might be able to have worlists for things like py3 migration and maybe priority reviews.
21:14:18 <diablo_rojo> stories and tasks you created as well
21:14:49 <diablo_rojo> mattoliverau, yep :) and you could put that all in a board if you wanted or have them exist separately
21:14:59 <diablo_rojo> Depends on how you want to view the info
21:15:03 <diablo_rojo> and organize yourselves
21:15:35 <timburke_> py3 seems like it'd be its own story, with a (likely large) number of tasks to do the porting and testing
21:15:38 <timburke_> i think?
21:15:42 <timburke_> *shrug*
21:15:55 <diablo_rojo> Could be done either way.
21:16:04 <diablo_rojo> Depends on how granular you want to get I suppose.
21:16:50 <diablo_rojo> Looking at your wiki of priority reviews.. I might lean towards a worklist
21:16:53 <timburke_> are there guidelines on what makes sense as a story vs as a task? or is the expectation that teams will figure out what works for them?
21:17:11 <diablo_rojo> and then have a story for each of the py3fun tests, a story for middleware, and a story bor 'obj'
21:17:33 <diablo_rojo> and then the tasks would be the patches under each of those larger topics
21:17:40 <diablo_rojo> Make sense?
21:17:51 <timburke_> i think so
21:18:08 <diablo_rojo> A task is the actual change in the repo. A story is the more general thing to get done
21:18:41 <diablo_rojo> So like.. if I had a new feature I would make a story for it and the tasks would be like.. a task for the cli update and another for the api change
21:18:55 <diablo_rojo> And if you did docs or tests as separate patches you could have a task for each of those too.
21:19:18 <diablo_rojo> If you wanted to do a release right after that you could also make a task associated with the releases repo in that story
21:19:25 <diablo_rojo> so that its all together in one place
21:20:12 <timburke_> cool
21:20:24 <diablo_rojo> Any other questions atm? :)
21:20:29 <timburke_> did anyone else have comments of questions for diablo_rojo?
21:20:54 <diablo_rojo> If you think of them later come bother us in #storyboard :)
21:21:04 <timburke_> cool, thanks diablo_rojo!
21:21:09 <timburke_> #topic libec
21:21:21 <timburke_> it's under openstack/ again!
21:21:33 <mattoliverau> nice
21:21:33 <kota_> nice!
21:22:03 <timburke_> new release synced over to https://github.com/openstack/liberasurecode/releases just fine
21:22:36 <tdasilva> sweeeeet!
21:22:57 <timburke_> i might poke at https://github.com/alpinelinux/aports/blob/master/testing/liberasurecode/APKBUILD to pick it up
21:23:02 <timburke_> in light of the impending https://review.opendev.org/#/c/662615/
21:23:03 <patchbot> patch 662615 - swift - Installing liberasurecode from Alpine Linux repos ... - 3 patch sets
21:23:58 <timburke_> we still owe the quadiron guys some reviews :-/
21:24:54 <timburke_> and i still need to follow up with the libphazr guys about whether they'd get broken by some of the proposed changes, and how we'd know without a gate job
21:25:20 <timburke_> but... that'll probably be later, because we've got other priorities!
21:25:23 <timburke_> #topic py3
21:26:03 <timburke_> i got some good comments on the ssync patch; pushed up a new patchset this morning
21:26:04 <timburke_> https://review.opendev.org/#/c/660542/
21:26:05 <patchbot> patch 660542 - swift - py3: port ssync - 5 patch sets
21:26:44 <timburke_> got the memcache fixup at https://review.opendev.org/#/c/662115/
21:26:45 <patchbot> patch 662115 - swift - Fix up how we memcache on py3 - 2 patch sets
21:27:02 <timburke_> that's going to be needed for tempurl https://review.opendev.org/#/c/652928/
21:27:03 <patchbot> patch 652928 - swift - py3: Port the tempurl middleware - 5 patch sets
21:27:54 <timburke_> on top of *that*, i've started working on getting func tests running under py2 passing against services running under py3
21:28:35 <timburke_> nothing in terms of a gate job just yet, but so far things are really promising!
21:29:05 <kota_> interesting
21:29:23 <timburke_> there were two spots of trouble i hit: first was non-ascii header names
21:29:37 <timburke_> which led to https://review.opendev.org/#/c/662546/
21:29:38 <patchbot> patch 662546 - swift - py3: Stop truncating response headers - 1 patch set
21:30:50 <timburke_> (see https://github.com/openstack/swift/blob/2.21.0/test/functional/test_container.py#L156-L163 for one of the tests that exercises that -- and note that it already has a `if tf.web_front_end == 'integral':` guard)
21:32:47 <timburke_> the other is something i happened to hit because i was using an EC policy by default -- apparently there's some bad interaction between SegmentedIterable and ECAppIter that trips a `ValueError: generator already executing` when closing iters at the end of the response
21:33:12 <timburke_> still not sure what's going on there, but it doesn't happen on py2 :-/
21:34:24 <timburke_> while trying to characterize that, i found https://bugs.launchpad.net/swift/+bug/1831790
21:34:24 <openstack> Launchpad bug 1831790 in OpenStack Object Storage (swift) "Multi-range GET of DLO returns bad data" [Undecided,New]
21:34:44 <timburke_> and proposed https://review.opendev.org/#/c/663403/ to fix it
21:34:45 <patchbot> patch 663403 - swift - dlo: Respond 200 on multi-range GETs - 1 patch set
21:35:06 <timburke_> apparently we never really intended to be able to do multi-ranged gets on DLOs
21:36:03 <timburke_> i think that's about all the progress i've got -- mattoliverau, zaitcev, anything to add?
21:37:42 <mattoliverau> Nice summary, nothing to add for me. I'll go look at the memcache one to hopefully unblock tempurl
21:38:26 <timburke_> mattoliverau, anything else you'd like before landing https://review.opendev.org/#/c/662294/ ?
21:38:27 <patchbot> patch 662294 - swift - py3: symlink follow-up - 2 patch sets
21:40:25 <mattoliverau> nope, I'm happy with it.
21:40:41 <timburke_> yay, more py3 func tests!
21:41:11 <timburke_> #topic lots of small files
21:41:25 <timburke_> rledisez, kota_, how's it going?
21:42:10 <rledisez> no real moves from ovh side. last there were a holiday and alex is sick these days
21:42:18 <rledisez> *last week
21:42:25 <mattoliverau> timburke_: +A'ed
21:42:42 <timburke_> thanks mattoliverau
21:43:00 <timburke_> i saw kota_ proposed a merge from master, which is great. just approved
21:44:37 <kota_> yup,
21:45:01 <kota_> but not yet have time to look at alex's test improvement sorry
21:45:56 <timburke_> is there any particular order we should look at things on https://review.opendev.org/#/q/status:open+project:openstack/swift+branch:feature/losf ?
21:46:15 <kota_> let me check
21:46:16 <timburke_> i know there are some unit test patches that conflict; which should we try to land first? i might make sure they can run under py3 ;-)
21:47:34 <kota_> i think, https://review.opendev.org/#/c/660381/ and https://review.opendev.org/#/c/659515/ are easy and able to be reviewed
21:47:35 <patchbot> patch 660381 - swift (feature/losf) - Add tests for vfile_utils - 1 patch set
21:47:36 <patchbot> patch 659515 - swift (feature/losf) - Add small unit tests for vfile and related modules - 2 patch sets
21:47:58 <timburke_> cool! sounds good
21:48:52 <kota_> Alex's improvement starts from https://review.opendev.org/#/c/659254/ ... not sure, but probably we need to know what exactly problem is
21:48:53 <patchbot> patch 659254 - swift (feature/losf) - In _get_vfile(), handle the case when a referenced... - 1 patch set
21:49:21 <kota_> I'll try to catch up those.
21:50:51 <timburke_> fwiw, notmyname got me excited about this over lunch yesterday -- reminded me that losf is giving us a model for how we can have more experimentation in the backend, and that getting https://review.opendev.org/#/c/427911/ really opens up the scope of what kinds of experiments would be possible
21:50:52 <patchbot> patch 427911 - swift - Replace MIME with PUT+POST for EC and Encryption - 37 patch sets
21:51:14 <notmyname> :-)
21:52:06 <timburke_> after py3, i'm fairly certain these should be the priority
21:52:21 <kota_> thanks a lot
21:52:47 <timburke_> #topic swift 2.22.0 release
21:52:49 <kota_> i know py3 is the top priority.
21:53:23 <timburke_> speaking of... i'd like to cut a release shortly after the py3 unit tests are ported
21:54:26 <timburke_> i maybe would've liked to have func tests, too, but i think we can get ourselves confident enough for "experimental" py3 support by running func tests manually under py2
21:55:17 <kota_> sounds reasonable to me
21:55:21 <timburke_> in light of that plan, what *else* should be getting in? anyone have patches they think would be good to land concurrent with the py3 work?
21:55:30 <mattoliverau> experimental py3 release would be exciting, and the distros would love to see that we've made that kind of porgress.
21:55:52 <timburke_> (alternatively, does anyone feel that this is a terrible plan and premature; we need to get func tests *first*?)
21:57:46 <mattoliverau> Well I'd like func tests, but if we can somehow do the py2 func to a py3 then I'm happy with that.
21:58:08 <timburke_> well, keep thinking about both what other patches we'd want for a release, and what we can do to feel more confident in the eventual (experimental) py3 support :-)
21:59:06 <timburke_> the sooner we can get the experimental release out, the more confidence we can have when we have for the *next* release when we say we *really* support it
21:59:24 <timburke_> we're about at time
21:59:35 <timburke_> thank you all for coming, and thank you for working on swift!
21:59:45 <timburke_> #endmeeting