21:02:03 <timburke> #startmeeting swift
21:02:04 <openstack> Meeting started Wed May  8 21:02:03 2019 UTC and is due to finish in 60 minutes.  The chair is timburke. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:08 <openstack> The meeting name has been set to 'swift'
21:02:22 <timburke> who's here for the swift meeting?
21:02:39 <kota_> o/
21:03:22 <kota_> lol
21:03:51 <timburke> i know thiago is going to miss it...
21:04:57 <timburke> well, thanks for being here kota_ :-)
21:04:59 <kota_> since we have the ptg until the last Saturday, everyone seems tiered, maybe?
21:05:10 <timburke> as much as anything, i wanted this just to write down some summaries from the PTG, so i think i'll go ahead and do that
21:05:13 <kota_> nope
21:05:31 <kota_> alright
21:05:34 <timburke> yeah, i'm guessing most people are still recovering, which is totally fine
21:05:41 <timburke> #topic PTG recap
21:06:13 <timburke> i feel like we did a pretty good job getting through the topics from the etherpad
21:06:36 <kota_> sure
21:06:47 <timburke> roughly in order of interest we had:
21:06:56 <timburke> #topic swift containerization
21:08:10 <timburke> we have a Dockerfile in tree now!
21:08:16 <timburke> tdasliva and cschwede have done a great job driving that work
21:08:22 <kota_> i saw that landed! yey!
21:08:28 <timburke> and i think having a dev test target that's easy to spin up is going to be great for us as a community
21:08:44 <timburke> #topic py3 support
21:09:31 <timburke> we've been making great progress! i've got a (fairly aggressive) plan to get all unit and func tests passing by the end of the month
21:09:39 <timburke> we'll see how well i stick to it ;-)
21:10:11 <kota_> ;-D
21:10:34 <timburke> the goal is to tag a release with experimental support early so we have a long period for further testing and validation before we have to tag a release for train
21:10:43 <clayg> sorry i'm late
21:10:53 <timburke> no worries! i was too :P
21:11:08 <kota_> clayg: hello!
21:11:13 <zaitcev> What I'm seeing right now is so absurd that I suspect jobs were marked non-voting by mistake.
21:11:14 <timburke> mostly i'm just trying to summarize ptg outcomes
21:11:16 <clayg> kota_: 🤗
21:11:21 <zaitcev> I mean, in the gate, and in the tree.
21:11:59 <timburke> zaitcev, how do you mean?
21:13:44 <zaitcev> actually, never mind.
21:14:04 <zaitcev> Apparently proxy/test_server.py was not yet converted.
21:14:50 <timburke> nope. working on it! i swear, https://review.opendev.org/#/c/657700/ worked on my machine ;-)
21:14:51 <patchbot> patch 657700 - swift - py3: finish porting proxy/test_server.py - 2 patch sets
21:15:54 <timburke> sorry, i did break that one up over several patches, just to try to isolate the rote '...' -> b'...' style changes from things that i actually needed to think about
21:16:05 <mattoliverau> o/ (sorry jetlagged and didn't realise the time)
21:16:06 <timburke> #topic losf
21:16:38 <timburke> looks like momentum's building on the feature branch!
21:16:38 <zaitcev> okay
21:17:04 <timburke> kota_'s been working on getting a func test job that uses the new backend
21:17:43 <timburke> and clayg's been working on making vagrant-swift-all-in-one know how to use it, too
21:18:20 <clayg> i also added some venv thing for py3 development that might be useful
21:18:26 <timburke> true!
21:18:40 <kota_> great
21:18:45 <timburke> there's still a good bit of work (such as writing unit tests, and integrating the golang unit tests into our gate), but it's great to see so much activity
21:18:52 <clayg> and I started playing with re-using the ansible jobs that run ceph in the gate to do more s3api testing on vsaio
21:19:05 <clayg> yay 👍 losf!!!
21:19:25 <timburke> #topic async delete patch
21:19:39 <timburke> #link https://review.opendev.org/#/c/648263/
21:19:39 <patchbot> patch 648263 - swift - WIP: s3api: Make multi-deletes async - 5 patch sets
21:20:47 <timburke> the consensus seemed to be that there were some interesting primitives introduced that might be generally useful, but the patch as it stands now isn't really something we want, particularly since it's only of use via the s3api
21:21:51 <timburke> i'm planning on seeing about breaking it up, maybe introducing an operator tool that utilizes the expirer-delete mechanism to mark an entire container for deletion, say
21:22:31 <timburke> with an eye toward eventually making it client-facing, complete with 410 behavior a la account reaping
21:22:42 <timburke> #topic general task queue
21:23:07 <timburke> there's been some progress (namely, you can now configure the expirer in object-server.conf)
21:23:58 <timburke> but m_kazuhiro is going to be moving on from swift development, so rledisez will be picking up the work
21:24:18 <timburke> #link https://review.opendev.org/#/c/517389/
21:24:19 <patchbot> patch 517389 - swift - Add object-expirer new mode to execute tasks from ... - 46 patch sets
21:24:44 <timburke> wow... 46 patchsets... yeah.
21:25:05 <timburke> #topic auto-sharding
21:25:07 <mattoliverau> Yeah, and maybe a few more before it lands
21:25:47 <timburke> mattoliverau had some good ideas about how we could decide on a leader based on replica number and ring version, which seems promising
21:26:10 <timburke> #link https://etherpad.openstack.org/p/swift-auto-sharding
21:26:37 <timburke> #topic s3 testing
21:27:03 <timburke> (i was going to say versioning, but i don't know that we really needed to talk much about the versioning api)
21:28:08 <timburke> clayg had the idea to have a test suite that we could point at either AWS (to ensure that our tests capture correct behavior) or Swift (to ensure that s3api implements the correct behavior)
21:28:41 <clayg> And timburke wrote it
21:29:00 <mattoliverau> :)
21:29:02 <timburke> and timur is taking on trying to transition our s3api func tests to using boto3 instead of boto, which'll be great
21:29:42 <timburke> there's still an open question of how much we want to test truely bimodal access, where you put data via S3 and read it via Swift or vice-versa
21:29:53 <timburke> but we don't currently have any tests like those, so... *shrug*
21:30:32 <timburke> #topic tempurl, SLOs, DLOs, symlinks, and security concerns
21:31:10 <timburke> we *think* there are more restrictions currently in place than are strictly necessary from a security standpoint
21:31:13 <timburke> probably?
21:31:20 <timburke> mattoliverau to investigate
21:31:41 <timburke> but it has implications for
21:31:43 <timburke> #link https://review.opendev.org/#/c/333331/
21:31:44 <patchbot> patch 333331 - swift - Preserve query params in tempurl - 4 patch sets
21:31:49 <mattoliverau> Ive started playing with some of this in func tests. Hope to have a start to something up soon
21:32:06 <timburke> yay! i'll keep it on the agenda for next week. thanks mattoliverau!
21:32:59 <timburke> #topic bucket policies
21:33:15 <timburke> and other aws-style lifecycle stuffty-stuffs
21:34:19 <timburke> ...there wasn't really much of an outcome. we kinda know that we want to do this, but no one's quite sure what it should look like
21:35:05 <timburke> maybe we could do something with some pluggability in s3api so something like 1space could hook into it and get the auth for free? still feels kinda weird
21:35:28 <timburke> #topic PUT+POST
21:35:53 <timburke> we still want to get back to standard HTTP
21:36:04 <timburke> likely with a goal of getting eventlet out of the object server
21:36:32 <timburke> #link https://review.opendev.org/#/c/582298/
21:36:32 <patchbot> patch 582298 - swift - PUT+POST: Detect older object server by not sendin... - 2 patch sets
21:37:39 <timburke> we have some idea of being able to link the file into place in the per-disk tmp while still using O_TMPFILE to ensure that we have it in the right xfs AG... we'll see how it goes
21:37:50 <timburke> #topic migration to storyboard
21:38:08 <timburke> we're gonna try it out! see what it's like in the sandbox, anyway
21:38:16 <timburke> thanks mattoliverau for being a liason there
21:38:34 <mattoliverau> I've asked diablo_rojo_phon to do a test migration to the sandbox. Will let you know when it's done
21:38:41 <mattoliverau> So y'all can have a play.
21:38:52 <mattoliverau> Probably won't be until next week tho
21:38:56 <timburke> great, thanks again!
21:39:00 <timburke> ...and i think that's about it
21:39:06 <timburke> #topic updates
21:39:30 <timburke> i know we just got back from the ptg so there probably hasn't been too much other than what's already been covered...
21:39:48 <timburke> but does anyone have anything in particular they'd like to share about ongoing bodies of work?
21:39:52 <diablo_rojo_phon> It's on my to-do list for next week
21:40:02 <timburke> thank you diablo_rojo_phon!
21:40:07 <mattoliverau> diablo_rojo_phon: ta
21:40:09 <diablo_rojo_phon> No problem :)
21:41:27 <timburke> so we'll check in on things again next week, when we've actually had time to code ;-)
21:41:33 <timburke> #topic open discussion
21:42:01 <timburke> there are a handful of mailing list threads that may be of some interest
21:42:09 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005956.html
21:42:45 <timburke> is just about a requests version bump on stable branches. i don't think it'll really impact us, but i'll try to get some DNM patches up to verify that things seem sane
21:42:51 <timburke> just something to be aware of
21:43:04 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005865.html
21:44:10 <timburke> is about same-company approvals -- i know i sometimes worry about gathering consensus around some swift patches, but it's getting harder and harder as our community is shrinking
21:44:22 <kota_> requests, i saw some dependencies around losf...
21:44:45 <timburke> as i recall, we also use it directly in s3token
21:44:47 <kota_> but probably fine to use the newer ones.
21:45:00 <timburke> and indirectly via keystonemiddleware
21:45:03 <mattoliverau> Yeah, it's a good rule of thumb, but to be honest I trust all our cores, no matter where you work :)
21:45:10 <timburke> and of course, there's pyhton-swiftclient
21:45:14 <kota_> and also python-swiftclient, i think
21:45:19 <kota_> timburke: :D
21:45:29 <mattoliverau> And until it does become an issue I feel we don't need to worry about it too much
21:45:41 <mattoliverau> Esp if we're doing the 1 +2 thing
21:45:52 <timburke> mattoliverau, yeah, that's the other half of it -- i don't really worry about anyone here ramming something in that isn't ready or shouldn't belong in swift
21:46:46 <timburke> i feel like i know you all well enough to say that you all have a very solid grasp of what makes sense for the project and the community and what doesn't
21:47:19 <timburke> again, just something to be aware of as a conversation happening in the larger openstack community
21:47:33 <timburke> and finally
21:47:35 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005871.html
21:47:52 <timburke> ...which sounds like a great plan. i've already responded
21:47:55 <timburke> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005917.html
21:48:36 <timburke> the tl;dr is, we're probably going to start running tempest tests again, but they should be better/faster/less flakey than they were
21:49:16 <timburke> sorry, that was a lot of stuff for me to write; does anyone else have anything they'd like to bring up?
21:50:04 <mattoliverau> Nope, great write-up timburke, nice coverage of the ptg
21:50:32 <timburke> does anyone have anything else they'd like to add/correct with regard to the ptg summaries?
21:51:04 <kota_> great summaries
21:51:30 <timburke> all right, i'm going to call it! thank you all for coming today, and thank you for working on swift!
21:51:46 <timburke> and of course, thank you all for coming last week! it was great to see you all
21:52:23 <mattoliverau> +2
21:52:32 <timburke> and finally, thank you for letting me get all of those outcomes/summaries down somewhere that i can reference again later ;-)
21:52:37 <timburke> #endmeeting