21:00:29 <notmyname> #startmeeting swift
21:00:29 <openstack> Meeting started Wed Mar  1 21:00:29 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:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:33 <openstack> The meeting name has been set to 'swift'
21:00:34 <notmyname> who's here for the swift team meeting?
21:00:37 <timburke> o/
21:00:41 <joeljwright> o/
21:00:43 <mattoliverau> o/
21:00:45 <mathiasb> o/
21:00:51 <kota_> o/
21:00:51 <pdardeau_> hi
21:00:52 * clayg lurks
21:00:55 <ntata> hello
21:01:30 <torgomatic> hi
21:01:46 <sgundur> hi
21:01:58 <acoles> hi
21:02:01 <notmyname> welcome, everyone
21:02:04 <m_kazuhiro> o/
21:02:32 <clayg> where's onovy and rledisez
21:02:55 <notmyname> they're not normally here, but it's also very late for them
21:03:00 <notmyname> cschwede: ?
21:03:02 <notmyname> tdasilva: ?
21:03:07 <tdasilva> hello
21:03:15 <tdasilva> i'm half here ;)
21:03:31 <clayg> maybe we should do one of those global timezone calendar things agains and sanity check our meeting time
21:04:12 <notmyname> clayg: best time globally is 7 or 8am us pacific time. that's never seemed too viable, unfortunately ;-)
21:04:22 <notmyname> ok, let's get started
21:04:26 <notmyname> good to see everyone here
21:04:35 <notmyname> agenda is at...
21:04:39 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:04:50 <notmyname> #topic PTG summary
21:05:01 <notmyname> I wrote some thoughts about the PTG at http://lists.openstack.org/pipermail/openstack-dev/2017-February/113062.html
21:05:13 <notmyname> our notes are collected at (or linked from) https://etherpad.openstack.org/p/swift-ptg-pike
21:05:32 <notmyname> if you've got something more detailed about a particular topic, PLEASE link to it from the ideas page
21:05:41 <notmyname> https://wiki.openstack.org/wiki/Swift/ideas
21:06:00 <notmyname> and project team photos are at https://www.flickr.com/photos/152419717@N06/sets/72157680602754246/ (if you missed it)
21:06:24 <notmyname> ok, I think that's it for general purpose links :-)
21:06:33 <notmyname> so... what'd you think? how was the PTG?
21:06:38 <notmyname> clayg: how was the food?
21:06:39 <notmyname> ;-)
21:06:52 <notmyname> (I'm kidding. don't talk about the food)
21:07:11 <kota_> lol
21:07:17 <mattoliverau> PTG was good. much better then I expected it to be
21:07:50 <clayg> OS - keeping expectations low
21:07:58 <notmyname> ouch
21:08:07 <acoles> notmyname: nice write up
21:08:12 <notmyname> mattoliverau: anything more than that?
21:08:14 <notmyname> acoles: thanks
21:08:14 <mattoliverau> as always we had alot going on, and multiple discussions going at once in the Swift room.
21:08:38 <mattoliverau> But I really enjoyed the hallway track as well. So it was good that other projects were around
21:08:48 <notmyname> yeah, that was good
21:09:05 <notmyname> of course the PTG is new, so it's hard to compare with what we've done in the past. and the upcoming summit is the other parts of the big rescheduling changes
21:09:17 <notmyname> I"m planning on having more info for everyone about the summit by next week
21:09:19 <acoles> IMO the 3 swift days were as productive as previous midcycles
21:09:36 <notmyname> were we negatively impacted by it being 3 days instead of 4?
21:10:00 <notmyname> did we lose anything by not having a sponsored evening group activity?
21:10:48 <notmyname> were the first two days effective and useful for the swift community? (ie yes, it's good to work with different projects, but was that productive with regard to making an awesome storage system?)
21:10:52 <mattoliverau> I think the 3 days didn't impact us too bad, as we broke up into small discussions early (from the start).
21:11:00 <mattoliverau> Though I do miss the Ops feedback
21:11:06 <notmyname> mattoliverau: YES!
21:11:47 <notmyname> was there anything that you'd change for the next PTG?
21:12:02 * notmyname is trying to prompt responses
21:12:09 <acoles> once or twice i was aware of two simultaneous discussions that I would like to have been in but that has happened at 4 day events as well
21:12:10 <tdasilva> get onovy and briancline there ????
21:12:12 <kota_> if it could be
21:12:37 <acoles> did we get many ops to midcycles before? or mainly at summits?
21:12:41 <kota_> swapping project specific days and cross-project days might be usefule?
21:12:51 <kota_> useful
21:12:53 <tdasilva> kota_: i was thinking the same thing
21:13:17 <mattoliverau> acoles: nope good point
21:13:18 <kota_> to cover topics which is discussed not enough
21:13:22 <acoles> notmyname: re sponsored evening...we had kind people who organised dinner venues for us at PTG :)
21:13:23 <notmyname> acoles: yeah, briancline has been to at least on midcycle, IIRC (but sometimes the events blend together in memory)
21:13:26 <kota_> which are
21:13:31 <notmyname> kota_: that's a really interesting idea
21:13:49 <clayg> acoles: IIRC we've historically had more ops feedback at the design summits - but we had ahale one time in san antonio and it was great
21:13:58 <clayg> I love ops - they can come hang out anytime
21:13:58 <kota_> not sure it works well for cross projects
21:14:01 <jrichli> sorry im late
21:14:03 <acoles> clayg: right
21:14:20 <notmyname> kota_: do you mean that the last two days would be for cross project but could be used for project-specific stuff as necessary?
21:14:37 <kota_> notmyname: yes
21:15:31 <notmyname> any other feedback on the week? other comments or suggestions that we can take to the larger openstack community?
21:16:09 <mattoliverau> Just better scheduling, its hard to search through everyones etherpad
21:16:26 <kota_> mattoliverau: +1
21:16:42 <torgomatic> try not to schedule on top of holidays?
21:16:46 <mattoliverau> And I miss the snacks and coke from developer lounge, but understand that costs money :)
21:17:13 <notmyname> torgomatic: in which country? but yeah :-)
21:17:19 <torgomatic> notmyname: host country, maybe
21:17:24 <tdasilva> notmyname: my thought with switching the days, is that we would be able to discuss things in project first which may raise questions for cross project later in the week
21:17:40 <mattoliverau> maybe more projector or sceens in rooms
21:17:44 <torgomatic> also, do we know yet if going to Boston will be useful for those of us who are only focused on development?
21:17:49 <tdasilva> not sure it makes sense, but the thought occurred to me...
21:17:51 <torgomatic> (sorry if that's a bit off topic)
21:18:09 <notmyname> torgomatic: that's what I want to learn myself this week and have info about during next week's meeting
21:18:17 <notmyname> tdasilva: yeah, that makes sense
21:18:25 <mattoliverau> torgomatic: I think the Sydney forum might clash with an Oz holiday. so yeah
21:18:26 <torgomatic> notmyname: 👍
21:18:51 <acoles> mattoliverau: is there a day in AU that is not a holiday ? ;)
21:18:53 <notmyname> tdasilva: alternatively, the later discussions we had in the week were simpler because you'd *already* figured out devstack/infra stuff at the first of the week :-)
21:19:08 <mattoliverau> acoles: a few, like next tueday.. that isn't a holiday :P
21:19:25 <joeljwright> :D
21:19:47 <tdasilva> notmyname: yeah, that's what i was trying to figure out...is the same true about barbica for example?
21:20:40 <notmyname> hard to say. hard to know what could have happened :-)
21:20:49 <notmyname> anything else to bring up before we move on?
21:21:27 <notmyname> overall, I thought it was a great week, and that's mostly due to you, the swift community. so thanks for being there
21:21:56 <notmyname> (and if you weren't there, you were missed) *cough*joel*cough*
21:22:23 <joeljwright> notmyname: thanks, I definitely feel like I missed out :(
21:22:34 <notmyname> mattoliverau: thanks for filling out the container sharding trello https://trello.com/b/z6oKKI4Q/container-sharding
21:22:59 <notmyname> #topic swift3+auth bug
21:23:05 <notmyname> timburke: your topic. what's up?
21:23:27 <timburke> bug's at https://bugs.launchpad.net/swift3/+bug/1561199
21:23:27 <openstack> Launchpad bug 1561199 in OpenStack Security Advisory "Client-accessible headers are used to send authentication information to other middlewares" [Undecided,Incomplete]
21:23:54 <notmyname> (note that it's public, despite being a security advisory)
21:24:11 <timburke> tl;dr is that from a presigned s3 url, an attacker can get access to everything the signer could access, rather than just the specific object
21:24:30 <notmyname> thanks :-)
21:24:48 <timburke> i mainly wanted to highlight that every auth middleware i've seen that supports swift3 has been affected, so anyone with in-house auth that integrates with swift3 should go audit to see if they're affected and plan on changing to the new env vars
21:24:50 <notmyname> and more specifically, it's related to the particular auth system that is being used (right?)
21:25:07 <timburke> i think beyond that, i just need notmyname to click the buttons on the swift patches
21:25:27 <notmyname> specifically, the backport patches so that the swift3 changes can be landed
21:25:42 <notmyname> since, in part, swift3 tests against swift stable and not swift master
21:25:42 <kota_> notmyname: yes
21:25:58 <notmyname> I'm planning on doing that this afternoon
21:26:38 <clayg> notmyname: this is https://review.openstack.org/#/c/438720 ???
21:26:51 <notmyname> timburke: and by "every auth middleware" you mean tempauth (dont' use this anyway), swauth, keystone. any others?
21:26:56 <timburke> re: auth system -- yup; it's a breakdown in input validation -- swift3 only does it's validation when the Authorization header starts with 'AWS ', while every auth system i've looked at will try to authenticate with *every* Authorzation header
21:27:11 <notmyname> clayg: actually the backport is https://review.openstack.org/#/c/438722
21:27:12 <timburke> swiftstack's auth
21:27:28 <timburke> i would expect anyone derived from tempauth to be similarly affected
21:27:29 <clayg> notmyname: is the plan... to land the backport before we land the change on master?
21:27:44 <notmyname> clayg: no
21:28:20 <notmyname> ok, let me rephrase my own plan: after my meetings are done today, I'll be looking at the patch to master (which timburke might already +A) and the proposed backport to see what needs to happen
21:28:22 <timburke> so go land 20 and then the backport (22), so i can land swift3's fix
21:28:23 <notmyname> :-)
21:29:03 <timburke> and if anyone has a better idea for how i can land critical security fixes in swift3 without needing swift backports, i'm all ears
21:29:52 <notmyname> timburke: general question about this... after landing, what breaks if someone upgrades without rewriting their auth integration?
21:30:04 <clayg> notmyname: the plan is for timburke to +A his own patch to swift master?  Even though he's currently asking if anyone has a better plan?
21:30:16 <timburke> notmyname: s3 api access
21:31:02 <timburke> we're making a conscious break to force middleware authors to deal with it
21:31:23 <kota_> neither older swift3 + new swift auth nor new swift3 + older swift auth works
21:31:33 <kota_> for s3 api
21:31:55 <timburke> clayg: i think this will have to be the plan for this fix. i'd be interested in ideas for avoiding backports to tempauth for future issues
21:31:57 <clayg> timburke: kota_: sounds ok to me!
21:32:32 <clayg> timburke: how do you avoid bacports if you make backwards incompatible changes?
21:32:38 <notmyname> what's the status of a swauth patch?
21:32:41 <clayg> do you want current swift3 to work with old swift or not?
21:33:13 <timburke> clayg: with old swift, yes. with old tempauth, i don't care so much
21:33:38 <timburke> notmyname: submitted https://review.openstack.org/#/c/439853/ -- passes gate, but i haven't func tested recently
21:34:04 <timburke> (it looks like swauth doesn't have func tests in the gate)
21:35:09 <notmyname> tempauth patch: needed for swift3 gate, swauth: should also bump the dependency on swift3, other proprietary auth: same as swauth but we can't patch it
21:35:12 <timburke> i'll probably submit a backport for keystonemiddleware, too, although the real solution there is to switch to using swift3's version of s3token
21:35:45 <notmyname> so timburke's point is that if you are running swift3, you need to examine your auth system, especially if it's something internal/proprietary
21:36:45 <timburke> and that's about all i had for that topic
21:36:57 <notmyname> ok
21:37:36 <clayg> timburke: and we can't just file a bug that says swauth doesn't work with swift3 > xyz?
21:37:44 <notmyname> and clayg's points/questions are good. we'll land master first. in this case, it's a patch to tempauth (which should be relatively low impact), but anyone else can also go review that if you're super concerned about it
21:37:57 <timburke> clayg: i might as well be a *little* more helpful than that
21:38:01 <clayg> there's a security bug in swauth that requires a change - so we may as well work with new swift3 while we're at it?
21:38:14 <notmyname> clayg: IMO yes
21:38:42 <notmyname> shall we move on to the last topic?
21:38:42 <clayg> notmyname: yes we *can* just file the bug?  Or yes there is a security hole that requires a change anyway?
21:39:10 <notmyname> clayg: yes there's a sec bug that requires a change anyway
21:39:14 <clayg> it's not writing the damn change - it's finding enough people to give a ^&*# about swauth+swift3 to get it landed?
21:40:35 <timburke> ...in which case swauth is screwed either way?
21:40:44 <timburke> i'm not sure i see your point
21:41:07 <notmyname> can we have that conversation either in -swift or somewhere else?
21:41:14 <timburke> sure
21:41:18 <clayg> sure
21:41:20 <notmyname> #topic Add X-Backend-Versioning-Mode-Override
21:41:31 <notmyname> timburke: this is also something you brought up. what's up here?
21:41:38 <timburke> so i'm going to talk about swift3 some more :P
21:42:05 <clayg> lol
21:42:23 <timburke> i've been working with an outreachy intern, karenc, who's been working on using the new history mode for versioned writes to implement s3-like versioning for swift3
21:42:37 <notmyname> that's cool
21:43:11 <clayg> timburke: there's a patch up right?
21:43:17 <timburke> she's submitted https://review.openstack.org/#/c/437196/ because she needed to be able to toggle between modes in some cases, and double POSTing to the container before doing an object delete seems like a Bad Idea
21:44:02 <timburke> clayg pointed out that it might be nice as a client-accessible feature, but i had some memory of us moving away from that during the review of https://review.openstack.org/#/c/437196/
21:44:31 <timburke> so i wanted opinions on whether to make this part of the public api or leave it just for middleware authors
21:44:44 <clayg> timburke: that's the same change?
21:45:11 <notmyname> shoudl be https://review.openstack.org/#/c/214922/
21:45:12 <timburke> bah. https://review.openstack.org/#/c/214922/
21:45:15 <timburke> yeah
21:46:07 <timburke> i'd pushed toward the latter (use an X-Backend-* header) just because if we change our mind later, it's easier to open it up than close it
21:46:31 <timburke> so, thoughts? tdasilva, maybe?
21:46:33 <notmyname> Adding X-Backend-Versioning-Mode-Override allows swift3 to override the
21:46:34 <notmyname> stored versioning mode for one request.  This means that even if the
21:46:34 <notmyname> versioning mode is set to "history", if the request has the header
21:46:35 <notmyname> "X-Backend-Versioning-Mode-Override: stack", swift will use "stack" as
21:46:37 <notmyname> the versioning mode.
21:47:14 <notmyname> so the question is, do we keep that as a private thing or allow end-users to use that (ie drop the x-backend- part)
21:47:28 <tdasilva> do we need to decide that now?
21:47:38 <tdasilva> i can look at it, but don't have an opinion now
21:47:58 <notmyname> tdasilva: you'd expressed hesitation earlier, and clayg suggesting it should be public. thus "meeting topic" ;-)
21:48:24 <notmyname> so, no, AFAIK we don't have to decide it right this minute (correct me timburke)
21:49:21 <timburke> only time constraint is that karenc's internship ends next week, but it sounds like she'll try to still get outstanding patches landed afterward
21:49:52 <clayg> timburke: is there a swift3 change that makes use of the header?
21:49:59 <tdasilva> timburke: please don't let me hold up things, i only meant to say i'd have to load this stuff up in my head again and think it through...
21:50:30 <tdasilva> but i trust others to make the right decision, so don't wait up for me if you can move things forward
21:50:31 <timburke> tdasilva: yeah, no worries :-) i'd prefer a thought-through response over a snap judgement
21:50:59 <clayg> timburke: notmyname: the history on patch 214922 - do you have he specific comment/context where someone said "clients should not be able to set version mode per request because xyz"
21:51:06 <timburke> clayg: not yet. it'll probably be part of https://review.openstack.org/#/c/436571/ but right now i think that just does the double-post thing
21:52:05 <timburke> on ps3, "The part I'm a little hesitant about is with the query parameter. I don't really see the need for it, why not just make it a configuration option. In this case I think I'd prefer the simplicity of having one or the other, but not both."
21:52:44 <clayg> timburke: so I don't love the idea of merging a string for some middleware to pull at and supporting that interface without functionally testing all the bits work together the way we want to solve the use-case
21:53:33 <clayg> timburke: if we make it a proper swift feature we can move orthogonally to the middleware - if it's just there for swift3 - I'd like to know it works for swift3 - I think that's about the whole of it
21:54:45 <timburke> clayg: even if it works for swift3 now, you wouldn't know when you break it later anyway. that's why swift3 is gating off ocata and not master -- we have a habit of breaking internal interfaces
21:54:59 <clayg> timburke: wasn't that concern raised before containers *had* a versioning mode?
21:55:51 <clayg> timburke: that we have containers with a default versioning mode - and you can flop containers back and forth - is it really so insane to think you can flop individual requests off the default mode per request (should probably be a qs)
21:57:05 <clayg> timburke: ok, and I think we should do better at that - one part of that strategy is being smart about the interfaces we "support" - and avoiding swift3 digging magic roots into other middlewares that only make sense in the context of swift3?
21:57:42 <notmyname> I wish we'd been able to discuss this topic (new external or internal api headers) last week
21:57:48 <clayg> anyway - my vote is the same 1) it could totally be a public client feature if someone wanted that and it would make it easier to maintain 2) if we don't want to do that work lets at least make sure it works for the consumer it's intended for
21:58:05 <clayg> why didn't we?
21:58:17 <notmyname> we're running out of time in here in the meeting room
21:58:22 <timburke> ...not many people care about swift3?
21:58:49 <notmyname> so what's the conclusion for this topic? timburke anything specific to do next?
21:58:59 <mattoliverau> I'm not against it becoming a public API, execpt that once it's pulically a part of the API we can't (or don't) remove it. So rather be a thought out decision before we add something. Though in this case I don't realy see the harm.
21:59:02 <clayg> that's too bad!  I'd like to get better at using swift3!
21:59:30 <timburke> i guess i need to push toward having a swift3 patch that uses the functionality. even though swift3 can't have any functests for it
21:59:41 <notmyname> mattoliverau: " I don't see the harm" <-- dangerous words ;-)
21:59:46 <mattoliverau> lol
21:59:53 <notmyname> timburke: ack
22:00:13 <clayg> timburke: we should work on swift3 having a gate against master - and eventually having swift cogate with swift3 as well
22:00:16 <mattoliverau> yeah, which is why tdasilva's loading into brain and thinking about it is important ;)
22:00:47 <notmyname> tdasilva: did you see how mattoliverau just avoided reviewing the patch by saying you would? ;-)
22:01:05 <tdasilva> lol
22:01:06 <notmyname> timburke: I like your thought on getting the swift3 patch in
22:01:09 <notmyname> ok, we're at time
22:01:11 <mattoliverau> damn you saw through it :P
22:01:14 <notmyname> mattoliverau: lol
22:01:27 <notmyname> thank you, everyone, for coming. thank you for your work on swift
22:01:30 <notmyname> #endmeeting