21:01:10 <mattoliverau> #startmeeting swift
21:01:11 <openstack> Meeting started Wed Nov 21 21:01:10 2018 UTC and is due to finish in 60 minutes.  The chair is mattoliverau. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:14 <openstack> The meeting name has been set to 'swift'
21:01:27 <mattoliverau> hey everyone
21:01:31 <mattoliverau> who's here for the swift team meeting?
21:01:35 <timburke> o/
21:01:42 <kota_> hello
21:01:45 <rledisez> hi o/
21:02:05 <mattoliverau> still waiting on tdasilva
21:02:12 <mattoliverau> who seems to be in channel
21:02:33 <tdasilva> hello
21:02:57 <mattoliverau> Not expecting a lot of turn out this week, because of thanksgiving in the US
21:03:23 <mattoliverau> So this will just be a status meeting. So should go pretty quick
21:03:34 <mattoliverau> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:04:33 <mattoliverau> before we get to the agenda, I'm curius to those who where there, kota_ and rledisez, how was the summit?
21:05:02 <kota_> that was good except notmyname absent project onboarding.
21:05:13 <mattoliverau> yeah, opps. :(
21:05:16 <kota_> absent from
21:05:35 <mattoliverau> other then that how'd the onboarding go?
21:05:35 <rledisez> it was ok. some interesting sessions on various topics
21:05:46 <rledisez> not a lot related to swift, sadly :)
21:05:48 <timburke> apparently somebody *cough*rledisez*cough* kept him out too late the night before ;-)
21:05:52 <mattoliverau> :(
21:06:02 <mattoliverau> ahhh, so that's what happended ;)
21:06:11 <rledisez> timburke: there is no proof :p
21:06:15 <mattoliverau> lol
21:06:22 <tdasilva> rofl
21:06:44 <kota_> one interesting session I found, wait a moment, i'm looking for the slide...
21:07:05 <mattoliverau> re: not a lot related to swift, sadly: We may need to make swift less stable so people take more notice ;)
21:07:11 <mattoliverau> kk
21:07:35 <timburke> or find other conferences to check out...
21:07:46 <kota_> #link https://dirkmueller.github.io/presentation-berlin-log-classify/#/
21:07:54 <mattoliverau> true, maybe something storage focused
21:08:30 <kota_> that was present by Tristan@RedHat
21:08:43 <kota_> introducing how we reduce noisy logs in the gerrit/zuul.
21:08:59 <timburke> kota_: that *does* sound interesting!
21:09:00 <mattoliverau> and Dirk it seems
21:09:05 <mattoliverau> I work with him
21:09:06 <kota_> basically, that reduces anoying setup logs.
21:09:43 <kota_> then, it will show anomaly logs when the gate failed.
21:10:06 <kota_> timburke: i thought you like it ;)
21:10:36 <mattoliverau> cool. I shall go and actaully watch that one.. I asusme it would have been recorded
21:10:57 <mattoliverau> any other highlights?
21:11:26 <mattoliverau> we can always ask again next week to get notmyname's summit highlights too :)
21:11:43 <kota_> i think it was recorded but it seems like the video has been delayed in this summit.
21:11:56 <kota_> mattoliverau: good idea
21:12:14 <mattoliverau> well no links here then, but will keep my eye out.
21:12:19 <mattoliverau> let's move on then.
21:12:29 <mattoliverau> #topic Priority Reviews
21:12:39 <mattoliverau> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:13:42 <mattoliverau> we seem to have a general task queue topic later.. so we can talk about that then.
21:14:05 <mattoliverau> Seems to not have changed much. Which is fine.
21:14:24 <mattoliverau> timburke, kota_ hows the s3api patches.. need any love from us?
21:14:48 <timburke> i've got a couple new s3api patches, too :-) https://review.openstack.org/#/c/618301/ adds a concurrency factor for multi-delete requests, similar to what we already have for bulk, and https://review.openstack.org/#/c/619127/ adds a config option to allow some specific subset of AWS's server-side-encryption options
21:15:23 <timburke> i know tdasilva was interested in kota_'s opinion on https://review.openstack.org/#/c/592231/
21:15:30 <kota_> ah... I know them, sorry no updates for this time, I just finished another one than the last 2 things.
21:15:31 <mattoliverau> cool
21:15:41 <mattoliverau> ahh no notmyname means no patchbot. shame
21:16:14 <kota_> then, I won't have this week and the next week because of the technical *NTT* conference in my office location.
21:16:21 <mattoliverau> timburke: did you want to add them to the s3api list there? or do you feel their not a priority
21:16:21 <kota_> sorry.
21:16:44 <mattoliverau> kota_: no worries, these things happen
21:17:44 <timburke> mattoliverau: yeah, i'll probably do that. they came up as customer issues, so i'm gonna carry some (more) patches on swift3, which puts me further off from being able to switch to s3api :-(
21:17:59 <timburke> kota_: don't worry :-) enjoy the work conference!
21:18:41 <mattoliverau> timburke: yeah, we don't want that. I'd rathere have you pushing patches upstream then loose you to maintain downstream patches!
21:18:48 <mattoliverau> ;et
21:18:52 <mattoliverau> let's add them
21:19:10 <timburke> i can do both :-)
21:19:20 <mattoliverau> maybe I should finally stop being lazy and learn more of the s3 api so I can help review
21:19:22 <timburke> at least for a while
21:19:33 <mattoliverau> :)
21:19:43 <mattoliverau> cool
21:19:46 <mattoliverau> The undelete accounts is on me, but I haven't really gone and helped like I said yet. Been too busy with SUSE work :(
21:20:12 <kota_> mattoliverau: no worries
21:20:31 <timburke> fwiw https://github.com/swiftstack/vagrant-swift-all-in-one configures s3cmd pretty well, and i've got a patch up to have it also configure awscli for you
21:21:18 <timburke> i like that i can use aws's own tooling to test my changes :-)
21:21:22 <mattoliverau> but from what I can see, if we add the ability to undelete accounts (officially) then we need to support it. and there is a eventual consistency issue when a reaper may delete _everything_ if something has been undeleted. So I think some kind of qourum needs to be added, if we want to support it.
21:21:41 <mattoliverau> timburke: ahh cool, I should take a look at that
21:22:28 <mattoliverau> I offered to help write some quorum check, but haven't had a chance...
21:22:44 <mattoliverau> I should go and at least let them know I'm not dead.
21:23:29 <mattoliverau> The only other patch on the priority reviews is the keymaster nice to have. and the swift-object-info one.
21:23:47 <mattoliverau> I did review it a while ago. timburke is it ready for another review?
21:24:17 <timburke> oh, i forget. i'll take a look today
21:24:22 <mattoliverau> I know you have alot of patches in the air, so maybe this one isn't really a hight priority
21:24:37 <timburke> speaking of keymasters, i keep meaning to review your https://review.openstack.org/#/c/591555/ mattoliverau
21:25:19 <timburke> i guess i'll break down and actually have my barbican config under /etc/ -- i managed to get keystone happy running from somewhere else, but i haven't been able to do the same for barbican...
21:25:20 <mattoliverau> yeah, I'd love to see that in the next release, just so all our keymasters (upstream) have the same set of features. maybe I should add that to the priority reviews section?
21:26:10 <timburke> i like it. i feel like it ought to be higher priority than the object-info guy, anyway
21:26:28 <mattoliverau> timburke: I used the saio install script/env that tdasilva forked when we were first reviewing the kms keymaster orginially :)
21:26:50 <timburke> it all *looks* right -- i just wanna remember how to functionally test again :-)
21:26:59 <mattoliverau> :)
21:27:05 <mattoliverau> I'll add it to the page.
21:27:07 <timburke> then maybe i could add barbican to our dsvm job...
21:27:44 <mattoliverau> not a bad idea
21:27:53 <tdasilva> https://github.com/thiagodasilva/barbican-swift
21:28:19 <mattoliverau> also makes us look better doing more cross project testing
21:28:30 <mattoliverau> not that we'd install barbican master tho
21:28:55 <mattoliverau> tdasilva: that's the one, I forked and use that when I want to test kms, because I'm lazy
21:29:04 <tdasilva> cool!
21:29:34 <mattoliverau> why reinvent the wheel, when tdasilva or timburke has already invented it ;)
21:29:55 <timburke> but what if i can *make a better wheel*!? :P
21:30:14 <mattoliverau> lol, it's called a PR ;)
21:30:34 <tdasilva> if you are in the business of making wheels...
21:30:54 <mattoliverau> then that's a different story I guess.
21:30:58 <mattoliverau> if there's nothing else on this topic, lets move on.
21:31:11 <mattoliverau> #topic task queue
21:31:22 <mattoliverau> Any updates on this?
21:31:38 <mattoliverau> tdasilva and myself worked on a documentation follow up patch.
21:31:49 <kota_> great
21:32:15 <mattoliverau> did that get sqashed in?
21:33:04 <kota_> no idea, m_kazuhiro doesn't seem to be here.
21:33:08 <mattoliverau> https://review.openstack.org/#/c/616076/
21:33:16 <mattoliverau> ^ documentation patch
21:33:40 <kota_> can i ping him in the day time in my time zone?
21:33:58 <mattoliverau> kazahiro left a comment saying he'd like to get rledisez review on it before sqashing it in.
21:34:12 <kota_> i see
21:34:29 <rledisez> mattoliverau: i'll try to have a look at it this week
21:34:36 <mattoliverau> And I have no doubt rledisez english skills are better then mine (Australian english == bad english) :P
21:34:45 <mattoliverau> ta.
21:35:04 <kota_> lol
21:35:05 <mattoliverau> but the doc patch doesn't stop people looking at the task queue patch.
21:35:29 <mattoliverau> anyway, this is just a reminder. If you have the time, I know we're all busy
21:35:44 <mattoliverau> next topic
21:35:48 <mattoliverau> #topic LOSF
21:36:04 <mattoliverau> rledisez: anything to update?
21:36:24 <mattoliverau> any reviews you want to point us at that we really should be reviewing for you?
21:36:42 <rledisez> not for this week. it's quiet on the losf side
21:36:56 <rledisez> we've been struggling with bugs that might be related to eventlet more than losf
21:37:15 <rledisez> a proper bugreport + patch is on the way about one of them, still digging for the others
21:37:18 <kota_> rledisez: it seems like Norio succeeded to run the Alex's branch in his env, he is now looking the diff to know how was implemented.
21:37:42 <rledisez> kota_: awesome, it's not only OVH work now ;)
21:38:03 <kota_> rledisez: that's my plan ;)
21:38:09 <mattoliverau> \o/
21:38:16 <mattoliverau> that's awesome news
21:39:03 <mattoliverau> I look forward to reading the bugreport.
21:39:31 <mattoliverau> maybe that reads bad. is it bad to look forward to reading bug reports?
21:39:47 <mattoliverau> i dunno, still pre coffee for me :p
21:40:00 <rledisez> mattoliverau: you loof forward to reading the bugreport that will contain a link to the patch, right? :D
21:40:28 <mattoliverau> oh yeah, well that certainly is true ;)
21:40:39 <kota_> lol
21:41:20 <mattoliverau> but if you get blocked and need more eyes and heads then get the bugreport in. Especially if it's due to eventlet, clayg would love more fodder against eventlet I'm sure :)
21:41:49 <mattoliverau> Cool, then lets move on the last topic.
21:41:56 <mattoliverau> #topic open discussion
21:42:09 <mattoliverau> Anything else anyone wants to bring up?
21:42:22 <rledisez> mattoliverau: back to the subject, the more we go, the more I want to drop eventlet. is there somewhere an idea of a plan to do that?
21:42:31 <timburke> encryption got ported to py3!
21:43:10 <rledisez> my first though was to get uwsgi in, to do the "prefork" stuff, then remove eventlet step by step. does it sounds crazy? what about having uwsgi as dependency… so man questions :)
21:43:33 <timburke> rledisez: i know clayg feels the same way -- not sure about a concrete plan, though
21:44:03 <mattoliverau> yeah, that's similar to the plan clayg has
21:44:13 <mattoliverau> And I think makes sense.
21:44:27 <mattoliverau> Not sure we documented it anywhere.
21:44:59 <mattoliverau> I'll see if I can find any clay ramblings in etherpads about it. And let's add it to ideas to start fleshing out some more.
21:44:59 <timburke> were you thinking mainly for the backend servers, or proxy server as well? i could maybe see eventlet still kinda making sense on the proxy... idk. haven't thought about it enough.
21:45:32 <mattoliverau> based on that we'd hopefully know if it sinks or swims and can move on it, either way
21:45:34 <rledisez> timburke: yes, object server first. for proxy, it might be a good idea to keep it for now
21:46:31 <rledisez> i think i'll try something simple first, running object server in uwsgi with eventlet_tpool_size to 0 and see how it goes (performance & co). after that, we'll see if there is something to fo from there
21:47:15 <mattoliverau> with all the worker stuff starting to happen in the back end, it makes sense. currently I think we need to fork before eventlet monkey patches breaks things, so it definitely gets in the way.
21:47:16 <timburke> i think zaitcev's https://review.openstack.org/#/c/427911/ might still be a pre-req -- kinda depends on what the new server would do with the stray zero-byte chunk we stick into the mime doc PUT stream...
21:48:53 <rledisez> timburke: hum, i see, i will try to run func test on it to see what happen
21:49:07 <mattoliverau> rledisez: nice, see how that goes. But eventley does a bunch of monkey patching to other areas of python, so would a eventlet_tpool_size of 0 stop that, you may still end up fighting evenlet to some extent.
21:49:37 <mattoliverau> but only testing will tell
21:49:45 <timburke> yeah -- EC is where it'd bite you. see https://bugs.launchpad.net/swift/+bug/1496636
21:49:47 <openstack> Launchpad bug 1496636 in OpenStack Object Storage (swift) "EC: Chunked transfer/commit protocol is *not* HTTP" [Medium,In progress] - Assigned to Pete Zaitcev (zaitcev)
21:50:15 <kota_> :/
21:50:26 <rledisez> ok, so back to square one i guess
21:51:11 <mattoliverau> to go back a step, timburke yeah py3 encrption, nice!
21:51:58 <timburke> or, we keep moving forward on getting our "HTTP" protocol to actually be HTTP! and then we can (theoretically) use whatever WSGI server we want!
21:52:03 <mattoliverau> timburke: hows the py3 stuff going, I've seen patches for the account server, so you and zaitcev are doing awesome there.
21:52:15 <mattoliverau> timburke: +1
21:52:37 <mattoliverau> that's the whole point of using a standard :)
21:52:38 <timburke> ¯\_(ツ)_/¯
21:52:44 <timburke> who knows
21:53:07 <timburke> someday it'll all run under py3 -- hopefully it'll even upgrade all nice
21:53:16 <mattoliverau> lol
21:54:04 <mattoliverau> py2 > py3 is much more of a rewrite then I expected, and it always comes down to unicode and byte strings.
21:54:32 <timburke> there's probably going o be a long tail of fixes before we declare full support. like, we thought we had common.utils ported already, but nope: https://review.openstack.org/#/c/619109/1/swift/common/utils.py
21:54:43 <timburke> (thanks for merging that btw, mattoliverau)
21:55:50 <timburke> occasionally there are other issues -- like lists becoming iterators :-)
21:56:02 <mattoliverau> we may need to add to our developer documentation, for devs, on how to write code that behaves correctly (ie how and when to use str_to_wsgi etc)
21:56:16 <mattoliverau> timburke: yeah
21:56:21 <mattoliverau> and moving everything :P
21:56:35 <mattoliverau> ok only 4 minutes to go
21:57:10 <mattoliverau> I didn't expect the meeting to go as long.. but then again, I'm not very short winded.
21:57:48 <mattoliverau> Anything else to bring up before the end of the meeting?
21:58:12 <mattoliverau> going 1...
21:58:17 <mattoliverau> 2...
21:58:22 <mattoliverau> ...3
21:58:34 <mattoliverau> the channel my inner notmyname: thanks for your work on swift!
21:58:38 <kota_> thanks mattoliverau
21:58:40 <mattoliverau> #endmeeting