21:00:37 <notmyname> #startmeeting swift
21:00:37 <openstack> Meeting started Wed Mar 30 21:00:37 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:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:40 <openstack> The meeting name has been set to 'swift'
21:00:47 <notmyname> who's here for the swift meeting
21:00:55 <dmorita> hi
21:00:58 <jrichli> o/
21:01:00 <joeljwright> hey
21:01:02 <hosanai> o/
21:01:03 <m_kazuhi_> o/
21:01:05 <kota_> hello
21:01:07 <pdardeau> o/
21:01:30 <timburke> o/
21:01:48 <sgundur> hi
21:01:53 <clayg> yo!
21:01:55 <tdasilva> hi
21:02:23 <notmyname> torgomatic: ping
21:02:33 <acoles> sorry i'm late
21:02:36 <torgomatic> oh, would you look at the time
21:02:44 <notmyname> acoles: no worries. we all enjoyed your podcast
21:02:52 <acoles> :/
21:02:56 <clayg> yeah - acoles should do weekly podcasts
21:03:07 <tdasilva> lol
21:03:09 <dfg> o/
21:03:11 * acoles is leaving in embarassment
21:03:14 <clayg> dfg!!!!
21:03:19 <dfg> hey clayg
21:03:35 <clayg> dfg: is arewin still working on stuff?
21:04:02 <notmyname> hello everyone! good to see you
21:04:07 <dfg> clayg: ya but he's been sick that last few days.
21:04:09 <notmyname> several things to go over this week
21:04:12 <notmyname> agenda is at
21:04:17 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:04:49 <clayg> notmyname: looks good
21:04:50 <notmyname> #topic new core
21:05:29 <notmyname> I'm happy to announce that donagh is now part of swift core
21:05:49 <jrichli> donagh: congrats!
21:05:57 <notmyname> although not one of the most prolific community members, everyone respects his judgement and advice, and he helps make the project better overall
21:06:04 <kota_> congrats!
21:06:10 <pdardeau> congrats donagh!
21:06:12 <notmyname> unfortunately, he's been out and isn't online now
21:06:21 <notmyname> but I hope he'll see the transcript :-)
21:06:24 <acoles> donagh is sick today, i will relay congrats to him
21:06:25 <clayg> lol - perfect :)
21:06:30 <hosanai> donagh: congrats!
21:06:39 <notmyname> acoles: thanks :-)
21:06:41 <acoles> and remind him of the 10pm meetings
21:06:54 <notmyname> acoles: have you had your summer time change yet?
21:07:47 <joeljwright> notmyname: yes, summer time now
21:07:52 <acoles> yep
21:08:03 <notmyname> ah, good
21:08:09 <notmyname> so this meeting won't be changing to 11pm :-)
21:08:29 <notmyname> #topic release status update
21:08:30 <acoles> for cschwede it did, poor cschwede
21:08:35 <notmyname> yeah :-(
21:08:41 <notmyname> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090501.html
21:08:49 <notmyname> there's the release email I sent to the mailing list
21:09:01 <notmyname> thank you everyone for a great release!
21:09:08 <notmyname> it got finished up and cut late last week
21:09:43 <notmyname> this is our contribution to the mitaka release
21:09:53 <clayg> yeah concurrent reads - mattoliverau congrats on both your babies!
21:10:04 <clayg> mitaka is so lucky
21:10:15 <notmyname> from my perspective, this release went really well. I didn't feel like there was a huge time crunch or rush to get something in
21:10:36 <notmyname> what did you think? anything we should change for next time or that we did right that we should do again?
21:10:53 * dfg happy about conc read too :)
21:11:32 <clayg> notmyname: i'm not sure really why this was release was any better than previous except for no storage policies or ec change series
21:11:45 <notmyname> yeah, I think that's a major part of it
21:11:58 <clayg> ... and then we *didn't* land encryption - which was sort of a booberries - but ultimately obviously the right call
21:12:22 <clayg> notmyname: probably we should take our pulse here and recognize that right before a OS cycle release is not when we want to land big things
21:12:46 <acoles> notmyname: it helped getting priority reviews wiki page up again for the pre-release weeks
21:12:48 <clayg> so coming into austin lets make sure that we can focus on what's left for encryption and stick with it - so we don't have to wait until the end of a cycle to make it happen
21:13:09 <clayg> planning future chnages - if it's not "basically merged" at the midcycle - we know we want want it in the cut
21:13:12 <clayg> IMHO
21:13:17 <notmyname> acoles: yeah, I liked the priority reviews page too
21:13:37 <notmyname> clayg: yep. I agree
21:13:41 <clayg> acoles: +1 - notmynames curation of the review backlog really help shape and focus the release - it's a killer feature
21:13:55 <notmyname> and, FWIW, I updated https://wiki.openstack.org/wiki/Swift/PriorityReviews again, post-release
21:14:02 <clayg> notmyname: nice!
21:14:10 <notmyname> it's largely the same, just doesn't say "mitaka" anymore
21:14:19 <notmyname> and I'll be spending some more time there
21:14:41 <acoles> notmyname: could we get the copy middleware patches on there?
21:14:45 <notmyname> I'm imagining a future hybrid of some sort between the wiki page and the list on http://not.mn/swift/swift_community_dashboard.html
21:14:59 <notmyname> acoles: yeah, it needs to be added. good call
21:15:09 <acoles> thanks
21:15:18 <notmyname> I'll do that right after the meeting, unless someone beats me to it
21:15:59 <notmyname> any other thoughts to share on this release before we move on?
21:16:29 <notmyname> ok, moving on
21:16:35 <notmyname> #topic rolling upgrades testing
21:16:43 <notmyname> remember the fire drill from last week?
21:16:50 <notmyname> in case you don't here's the summary:
21:17:06 <notmyname> the TC proposed removing the "supports rolling upgrades" tag from swift
21:17:42 <notmyname> (aside from being wrong) the consequence is that swift's maturity score, as published on the openstack website, would go down.
21:17:53 <notmyname> and that's terrible, especially right before a big marketing release
21:18:13 <notmyname> so the reason they proposed removing it is because we don't have a gate test that runs tests against a partially-upgraded cluster
21:18:28 <notmyname> eg upgrade storage nodes + old proxy + functests pass
21:19:06 <notmyname> so, first off, thanks especially to timburke acoles and cschwede who all jumped in to figure out how to actually do this sort of testing in the openstack CI system
21:19:26 <notmyname> because of that work, along with some help from -infra, we've made some good progress
21:19:32 <clayg> acoles: timburke: cschwede: wtg!
21:19:58 <notmyname> and the immediate removal of the tag has been delayed. ie we still have it, and the decision will be revisited "in a few weeks"
21:20:22 <notmyname> cschwede said he wouldn't make it to the meetign today, but here's a summary he sent earlier
21:20:37 <notmyname> "a quick note on the rolling upgrade tests: I’m working on a local dual-node test env, based on sdague’s patches to use that approach, but it’s not done yet. i’ll continue working on that"
21:21:00 <notmyname> the idea right now is based on https://review.openstack.org/#/c/297311/
21:21:00 <patchbot> notmyname: patch 297311 - openstack-infra/devstack-gate - Run swift services on subnode
21:21:31 <notmyname> this uses the "multinode" CI setup to have 2 VMs in a test job. one will have version X and the other will have version Y
21:21:42 <notmyname> (no I don't know exactly what X and Y are, at this point)
21:22:18 <notmyname> cschwede's work started slightly differently and has 3 patches that he's working on changing to work with the multinode setup (they are listed on the meeting agenda)
21:22:51 <notmyname> but the basic thing we've got to do now is figure out how to set up a ring that includes the other node in the multinode setup so that it's all one swift cluster
21:23:07 <clayg> goodness so devstack can do multinode deployments now too?
21:23:48 <notmyname> in all of this work, acoles discovered an important bug that we landed as an oversight.
21:23:54 <notmyname> https://bugs.launchpad.net/swift/+bug/1562083
21:23:55 <openstack> Launchpad bug 1562083 in OpenStack Object Storage (swift) "mid-upgrade clusters can cause versioned write errors" [Medium,New] - Assigned to Tim Burke (1-tim-z)
21:24:09 <clayg> yay thanks timburke !
21:24:16 <clayg> er... for assigning it :\
21:24:22 <notmyname> and it seems like timburke grabbed it 1 minute ago :-)
21:24:26 <timburke> ...and causing it...
21:24:33 <notmyname> I was just about to ask for someone to jump on it :-)
21:24:44 <clayg> yeah - no not that - i wasn't trying to make a back-handed compliment - happens to all of us!
21:24:49 <notmyname> the details (and mitigation) are in the bug report
21:24:50 <timburke> figured it was only appropriate
21:25:08 <notmyname> timburke: thanks (sincerely, unlike clayg ;-) for jumping on it
21:25:11 <clayg> timburke: and you just wrote it - reviews ensure all our mistakes can be equally blamed on everyone
21:25:28 <clayg> notmyname: i was being sincere!  :'(  it's the boy who cried wolf
21:25:40 <clayg> *this* time i wasn't being a jerk - promise!
21:25:42 <acoles> timburke: +1 for wot clayg said ^^
21:25:44 <notmyname> winkey face
21:25:55 <clayg> lol
21:26:02 <joeljwright> :D
21:26:26 <timburke> oh, i figured he was being sincere
21:26:29 <notmyname> any questions about the testing status, the need for it, the current bug, or what you need to do?
21:27:04 <clayg> notmyname: aside from comments form the peanut gallery I'm staying out of this one - looking forward to seeing the upgrade test running tho
21:27:36 <notmyname> my canned response is that if you don't know what to do, then your job is to review the patch when it comes in!
21:27:47 <notmyname> so we can blame bugs on all of us again :-)
21:28:31 <notmyname> moving on
21:28:35 <notmyname> #topic summit planning
21:28:42 <notmyname> woohoo. summit time
21:28:51 <notmyname> we've got about a month before the austin summit
21:28:57 <notmyname> I hope to see all of you there
21:29:12 <notmyname> the official schedule for the design summit should be published tomorrow, i think
21:29:26 <notmyname> but you can see the tentative one attached to http://lists.openstack.org/pipermail/openstack-dev/2016-March/090606.html
21:29:55 <notmyname> like in Tokyo, swift has 2 fishbowl sessions, 12 working room sessions, and 2 half-days on friday
21:30:22 <notmyname> as a reminder, fishbowl sessions are designed to be larger sessions that have more people in them. more like facilitated presentations/discussions
21:31:13 <notmyname> working sessions are more like what we do at hackathons. smaller rooms, smaller groups, more informal. they will not have a title published on the schedule, so as not to encourage a lot of looky-loos for popular topics
21:31:39 <notmyname> and the friday meetup is basically a free-form time that we'll have all day for
21:32:15 <notmyname> looking at the schedule so far, we've got a lot of big contiguous chunks of time
21:32:56 <notmyname> so like tokyo, I'd like to schedule them as "during the next block of time, let's cover these topics"
21:33:44 <notmyname> before tokyo, we did something more like scheduling one topic per time slot. that got really exhausting, mentally, and was too long for some things and too short for others
21:33:55 <notmyname> does that sound good to you?
21:34:03 <joeljwright> #agreed
21:34:13 <joeljwright> or whatever the command should be
21:34:14 <joeljwright> :D
21:34:18 <jrichli> +1
21:34:27 <dmorita> +1
21:34:30 <hosanai> +1
21:34:39 <torgomatic> do eet
21:34:46 <notmyname> great :-)
21:34:46 <clayg> %^&ing A
21:35:02 <m_kazuhi_> +1
21:35:25 <acoles> +1
21:35:57 <notmyname> the swift sessions will pretty much be wed-fri then. monday is ops feedback, and if there's any swift topics, that will be good to listen to. tuesday is for cross-project stuff. one cross-project thing proposed is about the (potential?) separation of design summit from conference
21:36:12 <clayg> notmyname: I still have this vague nebulous thinking that as we move our summit "presence" more toward working/hacking sessions we alienate some of the ... input?  interest?
21:36:17 <notmyname> so there's a lot to keep us busy (even if your company doesn't asign you to marketing booth duty)
21:36:48 <clayg> I'm not sure how helpful it is to have random happen-bys come in and start giving their opinions on stuff they don't know about or asking questions about stuff the room is already caught up on
21:37:15 <clayg> ... but there's bound to be an impact if most of the swift activity is "invisible" - dunno how much i care - but I tend to worry abou it come summit time?
21:37:36 <notmyname> yeah, I think that's an important thing to consider
21:38:05 <clayg> is the monday session in the fishbowl?  definately don't want to miss out hear from any other operators that make it to the summit
21:38:21 <notmyname> no, our 2 fishbowls are on wednesday
21:38:30 <acoles> the fishbowls can help in that respect, if we choose the right topics for them - in tokyo we had an ops fishbowl iirc?
21:38:30 <notmyname> I'm not sure how the ops sessions will be run/scheduled
21:38:33 <clayg> notmyname: and we're still working on what goes when - right?
21:38:50 <notmyname> right. perfect segue.
21:38:57 <notmyname> #link https://etherpad.openstack.org/p/swift-newton-summit-planning
21:39:08 <notmyname> put your topic ideas in there
21:39:23 <notmyname> and we'll build a general schedule from that
21:39:36 <clayg> acoles: yeah i agree if we only have two published fishbowls it's important to fill them with the right topics - and specifically not working/hacking topics - even if the subject matter bleeds into the work week and we have to go over it "again"
21:41:11 <notmyname> yeah, two fishbowls is hard.
21:41:51 <clayg> notmyname: do you want "interested" lines on these?
21:42:06 <notmyname> yeah, that would be great
21:42:08 <clayg> looks pretty empty - do you still have the pad from bristol-prep?
21:42:48 <notmyname> yeah, I just made it this morning :-)
21:43:13 <notmyname> clayg: https://etherpad.openstack.org/p/swift-hackathon-feb-2016
21:43:19 <clayg> notmyname: i'm expecting if we look at the mid-cycle topics there will be some overlappying - hanks!
21:44:14 <notmyname> I expect there will be topics for crypto and container sync and maybe for keystone
21:44:32 <notmyname> probably for client docs, client feature parity
21:44:41 <torgomatic> client feature parity?
21:44:47 <torgomatic> or am I about to be sorry I asked
21:44:54 <notmyname> torgomatic: making sure that the client actually supports all the things swift offers
21:45:09 <torgomatic> oh, right... parity with Swift. That's probably a good idea.
21:45:34 <notmyname> there will be a lot, I'm sure. it's not hard to come up with new topics to discuss :-)
21:45:56 <notmyname> please look over what's on the etherpad and think about what you'd like to see discussed
21:46:27 <clayg> k
21:46:43 <notmyname> In the meetings between now and the summit, we'll revisit the etherpad
21:47:26 <notmyname> anything else to cover on this topic this week?
21:48:39 <notmyname> #topic open discussion
21:48:46 <notmyname> anything else to bring up in this week's meeting?
21:50:15 <notmyname> ...and it seems like everyone is looking at or filling in stuff on the etherpad :-)
21:50:34 <notmyname> thank you for coming, everyone
21:50:41 <notmyname> thank you for working on swift
21:50:48 <notmyname> #endmeeting