21:00:05 <notmyname> #startmeeting swift
21:00:06 <openstack> Meeting started Wed Jan 27 21:00:05 2016 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:10 <openstack> The meeting name has been set to 'swift'
21:00:12 <notmyname> agenda is at
21:00:13 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:00:19 <notmyname> who's here for the swift team meeting?
21:00:25 <hurricanerix> o/
21:00:26 <jrichli> o/
21:00:27 <timburke> o/
21:00:28 <travisn> o/
21:00:28 <blmartin> o/
21:00:28 <Zyric_> hello
21:00:29 <ho_away> o/
21:00:29 <zaitcev> o7
21:00:30 <kota_> o/
21:00:31 <aerwin3> o/
21:00:32 <cbartz> me
21:00:34 <jlhinson> o/
21:00:34 <sgundur> hi
21:00:34 <m_kazuhiro> o/
21:00:37 <ahale> o/
21:00:37 <cutforth> o/
21:00:40 <timburke> zaitcev: broken arm?
21:00:41 <mattoliverau> o/
21:00:51 <acoles> here
21:01:00 <notmyname> timburke: salute, I think
21:01:06 <timburke> oh, of course! a salute!
21:01:07 <clayg> o/
21:01:09 <onovy> With beer here
21:01:20 <notmyname> welcome everyone
21:01:28 <clayg> ^ why you never bring in beer for swift meeting in SF officE!?
21:01:49 <notmyname> not a long agenda today, so we should be able to get through it quickly
21:01:58 <notmyname> #topic hackathon
21:02:31 <notmyname> first, touch base on the hackathon. anyone have any questions that need answered? everyone has their hotel and is working on flights (or already has them)?
21:02:38 <notmyname> acoles: anything we need to be updated on?
21:02:51 <acoles> we have >30 registered :)
21:03:08 <ho_away> wow
21:03:11 <zaitcev> I'm going to take a bus from LHR and I'm a bit concerned if it's a bad idea. But we'll see.
21:03:16 <acoles> if anyone has registered but is NOT able to come please let me know, I am starting to fret about space
21:03:35 <mattoliverau> If I was drinking beer for this meeting, then I'd have a problem
21:03:37 <kota_> zaitcev: me too :-)
21:03:39 <acoles> but then I will fret about something whatever :)
21:03:50 <torgomatic> o/
21:03:58 <acoles> the hotel group rate is gone I'm afraid
21:04:09 <joeljwright> morning/afternoon/evening everyone
21:04:51 <acoles> we have a nova midcycle on site this week so i am learning from their experience and we'll do better!
21:04:54 <onovy> mattoliverau: I had 3 beers and I'm fine :-)
21:05:00 <notmyname> acoles: :-)
21:06:17 <acoles> if anyone has questions just ping me
21:06:28 <notmyname> I'm looking forward to seeing everyone. thanks acoles for handling all the logistics
21:06:42 <acoles> (about the hackathon that is. diskfile questions go to clayg) :P
21:06:56 <notmyname> ;-)
21:07:00 <notmyname> #topic patches: auditor watches
21:07:06 <mattoliverau> acoles: oh the Nova one, 3 of my work mates are there.. there obviously the noisy Aussies.
21:07:12 <notmyname> patch 212824 patch 268830
21:07:12 <patchbot> notmyname: https://review.openstack.org/#/c/212824/ - swift - Let developers/operators add watchers to object audit
21:07:13 <patchbot> notmyname: https://review.openstack.org/#/c/268830/ - swift - Let developers/operators add watchers to account a...
21:07:42 <notmyname> these two patches (from torgomatic and Zyric_) are getting some, but not many reviews
21:08:12 <notmyname> the reasoning behind them is to help operators add functionality based on what's found on disks in the cluster
21:08:14 <torgomatic> I have some feedback on mine from Tim Burke that I need to go address, but more is always appreciated
21:08:45 <acoles> torgomatic: sorry, did a week really pass by :( i'll try to get to it
21:08:52 <notmyname> interestingly, I talked to someone this week who's doing the elastic-search stuff in openstack who would like this account list functionality for their uses
21:08:59 <clayg> i would be *so* much more interested in adding features (ionice/watchers/whatever) to our auditors if they were better at their job - lp bug #1183656
21:09:01 <openstack> Launchpad bug 1183656 in OpenStack Object Storage (swift) "object auditors don't finish" [Undecided,Confirmed] https://launchpad.net/bugs/1183656
21:09:51 <notmyname> clayg: thanks for bringing that up
21:10:06 * clayg hears notmyname say "again" under his breath ;)
21:10:21 <notmyname> what can we do to get progress on that?
21:10:41 <onovy> Send review?
21:11:06 <clayg> idk, i'm obviously worried about it but haven't produced code - but I have to admit it is aboslutly blocking me from being interested in adding more stuff to that sub-system - maybe htat odesn't matter - someone else can review them
21:12:08 <clayg> THEY DON'T FUCKING FINISH - why you wanna "do something to every object" - you don't know that you've hit every object - none of us do - grrrr....
21:12:23 <clayg> :)
21:12:32 <onovy> +1 for this
21:12:56 <onovy> But it finish on small clusters right?
21:13:19 <clayg> onovy: depends how often you release code/push rings - but yeah - lots of stuff works better at reasonable scale
21:13:26 <notmyname> onovy: generally yes. but that's part of what needs to be investigated
21:13:41 <clayg> notmyname: nayway - this is probalby off topic - sorry for the rant - i'm not even sure if it's a big change or not
21:13:51 <clayg> notmyname: you were saying adding watchers?
21:13:58 <notmyname> but it's important, like you said
21:14:07 <Zyric_> I'd be interested into looking into it, but I don't think I have the knowledge or scale to do so I could always try.
21:14:27 <notmyname> and, like you mentioned int he comments there, this is the kind of stuff that gets lost in a backlog
21:14:48 <notmyname> Zyric_: jump in! :-)
21:15:34 <torgomatic> ZBF auditors might finish
21:15:48 <torgomatic> I mean, they are a lot faster than the full-file slow ones
21:16:03 <onovy> I think this change is not too hard. Remember last position and continue from it
21:16:08 <clayg> torgomatic: yeah ZBF is fast - you add the watcher to the ZBF?
21:16:12 <notmyname> to summarize, we've got some patches that could make an improvement in quality of life for people, and we've got an old bug that seems very problematic. all of that needs looking at
21:16:14 <torgomatic> clayg: yeah, both
21:16:27 <torgomatic> some message tells the watcher which one it's in, so it can do stuff or not
21:16:27 <clayg> oh, yeah someone might want the md5 and not wanna read it again - smart
21:16:55 <notmyname> onovy: it would be nice if you and Zyric_ could look into that bug. ask questions, of course. but see if you can get to the bottom of it
21:16:59 <torgomatic> watcher only gets the metadata anyway, so ZBF is as good as any
21:17:11 <Zyric_> Sweet. I can give that a go, it is a major blocker to my work and I don't have a lot to do in the meantime - happy to be helpful
21:17:29 <onovy> notmyname: np, Marek can look into it
21:17:39 <notmyname> lol @ manager ;-)
21:17:42 * clayg considers that it's maybe not the bug - but my loud mouth that's the blocker :\
21:18:07 <onovy> :-)
21:18:53 <notmyname> one other patch I wanted to mention..
21:19:03 <notmyname> #patch 202411
21:19:04 <patchbot> notmyname: https://review.openstack.org/#/c/202411/ - swift - Add functional test for access control (RBAC) with...
21:19:10 <notmyname> acoles already has a +2 on it
21:19:25 <notmyname> ho_away: anything to do on that besides get another review?
21:20:01 <ho_away> notmyname: i got a comment from kota_. i need to update some doc.
21:20:07 <notmyname> ok
21:20:19 <mattoliverau> I'm finishing up looking at it, not that I'm a keystone expert or anything tho :)
21:20:28 <notmyname> so maybe we have have it merged by the next meeting :-)
21:20:32 <acoles> ho_away: were the test meant to work at all with tempauth? or just skip?
21:20:52 <ho_away> acoles: skip
21:21:27 <clayg> ho_away: did the keystone-swift-all-in-one PR get any more updates - or is it dead?
21:21:48 <clayg> ho_away: or do you have a fork or anything?
21:21:51 <ho_away> clayg: i still continue to update it
21:22:25 <ho_away> clayg: i will send PR to the repo in swiftstack later
21:23:04 <ho_away> clayg: yeah, i forked and updated on my repo.
21:23:08 <acoles> while people are banging on their keystone setups, we have this review pending too https://review.openstack.org/261395
21:23:18 <acoles> patch 261395
21:23:19 <patchbot> acoles: https://review.openstack.org/#/c/261395/ - swift - Update parameters about authtoken middleware in pr...
21:24:39 <ho_away> acoles: i will review it
21:25:06 <acoles> ho_away: thanks
21:25:29 <notmyname> next up is from cbartz
21:25:31 <notmyname> cbartz: are you around?
21:25:34 <cbartz> yes
21:25:50 <notmyname> #topic patch 199607
21:25:50 <patchbot> notmyname: https://review.openstack.org/#/c/199607/ - swift-specs - tempurls with a container-level scope
21:26:04 <notmyname> I need to look at this one again
21:26:28 <cbartz> so, in principle, I just wanted to get some more feedback on this spec, as I think there has been a lot of interest
21:26:54 <notmyname> glaning over the comments, mattoliverau seemed nearly ready to +2 it on the last patch set
21:27:28 <onovy> What about ionice patch?
21:27:37 <mattoliverau> I can't remember, I'll go back over it today
21:27:51 <joeljwright> really interested in this spec, was just wondering if we can find a way to let it interact with SLO/DLO to allow for large object creation within the prefix...?
21:28:13 <notmyname> cbartz: yeah, I remember it being a pretty interesting idea
21:28:34 <cbartz> joeljwright: why do you see a problem in the interaction with SLO/DLO ?
21:28:57 <joeljwright> the tempurl middleware removes SLO query strings and DLO headers
21:29:32 <joeljwright> would be really nice to allow them through in a sanitised 'only within the prefix' way
21:29:41 <clayg> notmyname: I think i might want to take a stab at updating our specs template
21:29:42 <notmyname> joeljwright: intentionally or as a bug?
21:29:53 <joeljwright> tempurl intentionally removes them
21:29:59 <notmyname> clayg: yeah, I want to have "Specs" as a topic at the hackathon. not here today
21:30:06 <joeljwright> to stop scope creep in what can be accessed
21:30:22 <timburke> you could configure the tempurl middleware to allow the DLO header, though, right?
21:30:40 <joeljwright> see the bug fix here: https://bugs.launchpad.net/swift/+bug/1453948
21:30:41 <openstack> Launchpad bug 1453948 in OpenStack Object Storage (swift) "[OSSA 2015-016] all PUT tempurls leak existence via DLO manifest attack (CVE-2015-5223)" [Critical,Fix released]
21:31:09 <joeljwright> to allow this we need to modify SLO and DLO middleware to be prefix-aware
21:31:21 <joeljwright> without the leak fixed by the previous bug
21:31:33 <joeljwright> we can't jus let it all through
21:31:34 <timburke> ah, right...i'd forgotten about that...
21:31:53 <joeljwright> I'm not really sure why SLO is disabled
21:32:06 <joeljwright> but it certainly is in kilo - the query strings are modified
21:33:00 <joeljwright> other than that, I'm really keen to see this spec merged :)
21:33:19 <notmyname> joeljwright: good questions
21:33:38 <notmyname> cbartz: will you have a chance to address those in the review comments or the spec itself?
21:33:49 <notmyname> (one answer may be "no, thats complicated")
21:34:13 <cbartz> notmyname: I can give a try
21:34:26 <joeljwright> I'm happy to help if I can
21:35:00 <notmyname> thanks
21:35:01 <cbartz> I would have to take a look at the above mentioned bugfix. with the help of joeljwright we could advance in this topic
21:35:14 <clayg> notmyname: ok this is great - I didn't even know the spec existed
21:35:44 <cbartz> but actually I have also an organisational question....do we have to wait for the spec to be merged before starting to submit patches
21:35:48 <clayg> cbartz: I would encourage you to enumerate use-cases instead of problem description - they're related but different
21:36:10 <zaitcev> it's possible to list outstanding specs with URL like this - https://review.openstack.org/#/q/status:open+project:openstack/swift-specs,n,z
21:36:17 <clayg> cbartz: I'd be particularlly interested if you have a tool/application/work-flow that is really drving this change vs. "wouldn't it be neat if we could XYZ"
21:36:39 <clayg> either is fine - but the first one is like *super* engaging
21:36:42 <acoles> joeljwright: cbartz there was also this related bug https://bugs.launchpad.net/swift/+bug/1449212 that it would probably be worth reviewing in this context
21:36:43 <openstack> Launchpad bug 1449212 in OpenStack Object Storage (swift) kilo "Container level temp URLs can unintentionally leak data." [Undecided,Fix committed]
21:36:58 <joeljwright> clayg: I can probably help with a use case
21:37:09 <clayg> joeljwright is the man!
21:37:40 <clayg> cbartz: did someone answer the spec -> code question?
21:37:42 <notmyname> cbartz: no, it's not required that a spec land before you start working on code. to clayg's point, the use case enumeration would probably help more people get excited about it, though
21:38:07 <clayg> cbartz: answer is no, feel free to push up a change to demonstrate the idea - maybe WIP it and link in the spec
21:38:47 <acoles> +1 for a link to the spec in the code commit message
21:39:11 <torgomatic> +1 to use cases; I like hearing about what concrete things people want so I can consider the problem better. developing some abstract capability isn't as interesting, personally.
21:39:27 <notmyname> cbartz: there you go :-)
21:39:56 <cbartz> ok
21:40:03 <notmyname> ok, a couple of other general things
21:40:14 <notmyname> #topic other...
21:40:46 <notmyname> patch 238799 has some reviews, but some good feedback from clayg. onovy looks like you said you were going to address the dependency?
21:40:46 <patchbot> notmyname: https://review.openstack.org/#/c/238799/ - swift - Change schedule priority of daemon/server in config
21:40:47 <clayg> notmyname: is it open?
21:40:47 <m_kazuhiro> notmyname: I have a topic.
21:41:09 <onovy> notmyname: if there is consensus about it, Peter will fix it
21:41:13 <notmyname> m_kazuhiro: yes. I wanted to bring that one up next
21:41:23 <m_kazuhiro> ok
21:41:47 <onovy> so, everybody is fine with drop psutil deps and write own "set priority" code?
21:41:52 <clayg> onovy: it's quite possible i'm the only one thinking about psutil as large-ish liability for a tiny little c-wrapper
21:41:59 <notmyname> onovy: less dependencies >>> more dependencies
21:42:03 <onovy> clayg: i agree with you
21:42:13 <torgomatic> sure; it's not the first use of ctypes we'll have
21:42:15 <onovy> notmyname: yep
21:42:25 <notmyname> ok, great
21:42:26 <clayg> onovy: but I think I've come around to the idea we should have ionice in the auditors as a config option (so you know - that's *progress* - my mind isn't set in *stone* or anything)
21:42:45 <notmyname> m_kazuhiro: wanted to bring up symlinks. what's going on with those?
21:43:06 <onovy> clayg: code for have ionice/nice in wsgi is really simple, so what don't give ops this options?
21:43:14 <notmyname> AFAIK, it's in the "good idea we should do it" stage. is there code yet?
21:43:43 <onovy> notmyname: ok, can you write conclusion to review pls? drop psutil if it's not needed
21:43:56 <clayg> onovy: i'll have to work on a responose - it's possible my current thinking/logic is not sound
21:43:59 <clayg> onovy: offline?
21:44:08 <notmyname> onovy: no. you don't need my permission there. the review comments stand :-)
21:44:12 <clayg> m_kazuhiro: you're working on symlinks?
21:44:37 <clayg> I thought hamdi was working on symlinks?  Or eran or one of jrichli's people or something?
21:44:37 <m_kazuhiro> I discuss symlink with hrou
21:44:50 <onovy> clayg: ok. i wrote something about container-server to review too, so if you can reply it will be fine
21:44:56 <onovy> (not now, later :)
21:45:05 <clayg> onovy: ;)
21:45:07 <m_kazuhiro> is hrou here?
21:45:13 <notmyname> doesn't look like it
21:45:29 <jrichli> I can ping him, if you like
21:45:31 <notmyname> m_kazuhiro: are you asking about when you can expect it to be delivered?
21:45:42 <clayg> lol - who's working on it!?
21:46:08 <onovy> clayg: so. you are ok with: ionice in swift for auditor without psutil, right?
21:46:12 <m_kazuhiro> notmyname: yes, and I have one suggestion
21:46:37 <acoles> AFAIK hrou is working on symlinks
21:46:43 <notmyname> m_kazuhiro: there's no answer to "when" right now. there isn't any code
21:46:47 <notmyname> m_kazuhiro: what's your suggestion?
21:46:53 <jrichli> clayg acoles: agreed, hrou - and I think some others with him
21:46:54 <clayg> onovy: i'll update the review
21:47:02 <hrou> hey guys I'm here now sorry about that !
21:47:04 <onovy> clayg: perfect, thank you
21:47:20 <kota_> m_kazuhiro: could you pastte the link of gerritt for symlink patch?
21:47:30 <notmyname> hrou: no worries. the topic of symlink status was brought up
21:47:32 <m_kazuhiro> I think there will be two versions of symlink.
21:47:34 <kota_> m_kazuhiro: i think there is already...
21:47:39 <clayg> hrou: didn't you do a pad - that was like "everything is broken" - and I was like "its on fire" - and then like... what happened next?
21:47:42 <kota_> unless i am dreaming.
21:47:45 <hrou> Yep I did !
21:47:49 <hrou> So where we left off was this
21:48:06 <hrou> We agreed that with post-as-copy that symlinks really can flow over the post to the target object and that's ideal
21:48:24 <hrou> While its not great, its not great in the same way as a regular post (when using post-as-copy) can be "not great" ;)
21:48:28 <kota_> hrou:!!
21:48:50 <hrou> So kota_ is this what you mean by two variants, the existing code (just about) for post-as-copy
21:48:58 <hrou> and than something else for fast-post (still working on this) ?
21:49:11 * notmyname really hopes we can kill post-as-copy
21:49:35 <hrou> me too :)  and I think that's the long term plan, that's why I felt there may be some hesitation with the two phase approach
21:49:45 <hrou> And I'd understand that hesitation ;)
21:49:46 <hrou> https://review.openstack.org/#/c/232162/
21:50:26 <hrou> But would love to discuss other thoughts behind that here ? :)
21:50:34 <acoles> hrou: does two phase imply so we'd add a feature before knowing how to make work with fast-post?
21:50:59 <hrou> acoles, yes and hence I'm not sure I'm a big fan of it, but kota_ I assume that was what you were suggesting to get something out the door faster ?
21:51:22 <hrou> Or kota_ did you mean two different implementations ? i.e. post-as-copy, flows over to target, and fast-post does something else ? Though not sure that's a good idea either
21:51:51 <kota_> hrou: idk, m_kazuhiro is working mainly :/
21:52:10 <notmyname> I need to close the meeting in a minute or two so I can go pick up my kids...
21:52:19 <clayg> notmyname: can you summarize?  post-as-copy is hard?  or fast-post is hard?  Do we know what behavior we *want* or we're crafting the api to what we think we can implement?
21:52:19 <hrou> kota_, lets continue the talk in the swift IRC channel ?
21:52:22 <clayg> oh :\
21:52:27 <clayg> well fuuu
21:52:34 <notmyname> clayg: did you have something?
21:52:45 <kota_> but tbh, i don't think we should *too* depends on fast-post spec.
21:52:45 <clayg> I wanted to ask if someone besides SwiftStack can look at IPv6
21:52:46 <clayg> https://review.openstack.org/#/c/270991/
21:52:54 <notmyname> +1
21:53:02 <clayg> it's not *super* important i suppose if no one besides SwiftStack is *using* ipv6
21:53:08 <kota_> should consider fast-post a bit :)
21:53:23 <clayg> I was acctually think it was more of an oppertunity for someone else in the community to lean a little bit about how to use/test it
21:53:36 <kota_> hrou: sure
21:53:43 <hrou> thanks!
21:53:48 <clayg> overall it ended up not being that big of an impact to support - the statd change was the last thing we needed to fix upstream
21:54:01 <clayg> well - upstream *swift* that is - the whole world is dragging their feet
21:54:23 <onovy> clayg: i will look
21:54:30 <timburke> also, i'd like some eyes on swiftclient: patch 259410, patch 265544, patch 265417
21:54:31 <patchbot> timburke: https://review.openstack.org/#/c/259410/ - python-swiftclient - Support uploading to an object in swift from stdin...
21:54:32 <patchbot> timburke: https://review.openstack.org/#/c/265544/ - python-swiftclient - Error with uploading large object includes unicode...
21:54:32 <clayg> so anyway - patch 270991 - has a bunch of my notes if you want to try and test ipv6 on your vm - get started early ramping up your inevitable adoption of the new world order!
21:54:34 <patchbot> timburke: https://review.openstack.org/#/c/265417/ - python-swiftclient - _RetryBody doesn't need to take explicit etag/cont...
21:54:35 <patchbot> clayg: https://review.openstack.org/#/c/270991/ - swift - Allow IPv6 addresses/hostnames in StatsD target
21:54:56 <clayg> wooo it's a free for all!
21:55:04 <acoles> all my patches :)
21:55:10 <notmyname> heh
21:55:15 <timburke> acoles: hey, only one of those is mine :)
21:55:23 <clayg> yes look at acoles patches gd - they're all awsome!
21:55:30 <notmyname> I need to run, so I'll close the meeting for whoever's in here next
21:55:34 <acoles> seriously though, any more opinions on https://bugs.launchpad.net/swift/+bug/1487791 ? since jrichli has a patch to fix it one way
21:55:35 <openstack> Launchpad bug 1487791 in OpenStack Object Storage (swift) "POST to DLO squashes data without fast-POST" [Undecided,Confirmed]
21:55:38 <notmyname> thanks everyone for coming today
21:55:41 <acoles> timburke: just kidding ;)
21:55:41 <clayg> timburke: are any of those like old/trivial - I think the _RetryBody one I looked at once?
21:55:46 <notmyname> #endmeeting