16:02:28 #startmeeting cinder 16:02:29 Meeting started Wed Sep 2 16:02:28 2015 UTC and is due to finish in 60 minutes. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:32 The meeting name has been set to 'cinder' 16:02:34 hi 16:02:36 hello 16:02:36 hi 16:02:36 hi 16:02:39 hi 16:02:40 Ok, let's get on it 16:02:41 hi 16:02:42 hi 16:02:42 hi again 16:02:45 Hi all 16:02:45 hi 16:02:48 howdy! 16:02:49 #topic L3 lessons learned 16:02:56 * bswartz lurks silently 16:03:02 hi 16:03:03 I'll try and be quick here 16:03:17 First, nice job everyone on working through crunch time 16:03:42 Couple of things that I always point out, that I want to point out again and try and clarify some things 16:03:51 First, process is great; but it's not full-proof 16:04:10 anybody that's been around for a release should realize that the last week and deadine days are VERY busy 16:04:23 the gate slows down, and sometimes breaks (as it did for us on Monday) 16:04:45 The point being, I don't care if you do all the right things, it's no guarantee that your code will land 16:04:56 so, lesson learned; submit EARLY 16:05:05 jgriffith, +1 16:05:07 and if your patch is stalled let people know 16:05:09 great point! we need to document it somewhere 16:05:26 another thing I'd like to point out.... 16:05:59 we have these etherpads and priority lists that people work off of 16:06:06 they're causing more harm than good i think 16:06:20 the fact is, we have launchpad, and things are targeted and prioritized 16:06:33 that should be the source of truth, and I'd ask that people reference that going forward 16:06:42 that ALSO means, update your items there 16:06:55 jgriffith: we had some success with etherpad in the past 16:06:55 if gerrit doesn't pick up your changes, update them, or let me know so I can update them 16:07:10 xyang1: I think etherpads are broken and have led to part of the problem 16:07:20 jgriffith: ok 16:07:30 xyang1: but regardless, it doesn't matter now; I'll bring this up at the summit 16:07:41 with alll of that... 16:07:44 let the games begin :) 16:07:45 jgriffith: +1 16:07:47 from what i've seen one feature of the etherpads is that it has the like core reviewer sign up thing, can that be done in launchpad too? or was that not really helpful? 16:08:11 patrickeast: well, the way i see it is it didn't work 16:08:17 ask tbarron how well it worked out for hime 16:08:18 jgriffith: +1 16:08:26 well it can work if the PTL is around to manage the list of items in the etherpad. if he's out, then it breaks down. 16:08:31 ask thangp and dulek how it worked out for the verisoned object changes 16:08:36 jgriffith: +1 16:08:38 hemna: ++ 16:08:41 launchpad is ultimately the source of truth 16:08:48 hemna: +1 16:08:54 ok.. let's not rat hole on this one 16:08:58 hemna: That was why I started udpating it. 16:09:05 #topic begging crying whining etc 16:09:06 jgriffith: That's a different case (versioned objects) 16:09:07 * jungleboyj needs to get better with Launchpad. 16:09:22 the versionedobjects patches are not on etherpad somehow 16:09:35 jgriffith, i think the core sign-up feature may have helped so you don't have 11 cores reviewing the same patch 16:09:39 Yeah, and they are *HUGE* 16:09:47 kmartin: bs 16:09:52 kmartin: :) 16:10:07 kmartin: it doesn't matter 16:10:08 cores should be reviewing patches and we should have core overlap on patches 16:10:13 kmartin: Once it gets two +2s, or a bunch of -1s then people stop reviewing it 16:10:16 hemna: +1 16:10:21 DuncanT: +2 16:10:30 DuncanT: +1 16:10:37 Well those 6000 line patch from some vendors take time :) 16:10:40 if I open a patch and it has 11 core reviews and is still in the queue we've got bigger problems :) 16:10:51 If anybody knows some magic to get a gerrit dash of things not -1d by a core, that's be useful 16:10:52 kmartin: and they should, and they should get more attention 16:10:56 kmartin: we don't have them this time around:) 16:11:05 kmartin: I don't think we've EVER had a problem of too many people reviewing a patch 16:11:09 anyway... let's move on 16:11:23 patrickeast: 16:11:36 yah, so there are two patches for Pure Storage 16:11:41 https://review.openstack.org/#/c/213855 16:11:44 jgriffith: Agreed, lets move on and work this out f2f in Tokyo. 16:11:48 https://review.openstack.org/#/c/214825/ 16:12:09 both fall into the 'driver feature impl for core feature that merged late' category 16:12:43 I'm +1 on merging both of these FWIW, my +2 is on both of them 16:12:55 the replication one understandably had some legitimate issues/push back, the unmanage/manage snapshot one is IMO relatively harmless 16:13:18 but the first one is missing a period :) +1 for merging both 16:13:28 patrickeast: +1 16:13:31 both met all of the original requirements and deadlines (if that actually matters :P) 16:13:32 +1 for both too 16:13:39 FTR I'm -1 on any of these sorts of merges 16:13:40 o/ 16:13:41 They both fall under the 'features we need more widely implemented' category 16:13:45 but not a -2 :) 16:13:51 jgriffith: thats a start! 16:14:14 DuncanT: but having '1' driver implement them is not "widely implemented" 16:14:14 so I'm on the fence 16:14:32 do we or don't we have a FF ? 16:14:34 It's also no different than what we ended up with on the old replication and the migration code 16:14:35 but someone has to be first through the door 16:14:48 simondodsley: ok, then it should be me :) 16:14:55 I don't have a problem merging them. Patrick put the work in and we would have a reference out there. 16:14:56 lol 16:14:56 simondodsley: or we go together :) 16:14:59 o/ 16:15:10 jgriffith: That's true enough, except there's a reference implementation for manage snap at least 16:15:10 hold hands and both jump off the cliff. 16:15:12 weee! 16:15:15 jgriffith: are you ready to go 16:15:18 hemna: :-) 16:15:26 DuncanT: ahh... yeah, that's a great point 16:15:42 DuncanT: and the manage snaps one actually is "good" 16:15:48 jgriffith: i'll jump on my own or in a crowd - i don't mind 16:15:54 So it sounds like everybody is in favor of both of these 16:15:56 so that's cool 16:16:00 jgriffith: If nobody else has implemented replication, then that's a reason not to merge that one 16:16:14 if they get reviewed and happen to make it before the cut then that's great 16:16:19 DuncanT: +1 16:16:50 sound good? 16:16:55 DuncanT: +1 16:16:59 jgriffith: maybe you can finish your replication and get merged together with Patrick's? then we'll have two reference imp 16:17:10 DuncanT, thingee had a dashboard at some point. will see if I can find it 16:17:13 manage snap one seems fine 16:17:17 DuncanT: can you clarify your statement, are you saying "it is" a reason, or that it's "failed logic"? 16:17:36 jgriffith: It is a good reason not to merge - only one implementation is bad 16:17:57 jgriffith: I thought there was another one in, if not then hold off merging IMO 16:18:07 DuncanT: thank you for the clarification, and that was kinda my point 16:18:29 egallen: simondodsley still agree with DuncanT 's statement? 16:18:34 DuncanT: disagree with the logic. Someone has to be first. 16:18:37 DuncanT: saying one implementation is bad kind of defaults the whole reference impl that goes with most features doesn't it? I understand the drawbacks (having discussed this with jgriffith several times) 16:18:45 holding off will allow us to come up with replicationV3 in Tokyo? 16:18:49 Just because no one else was ready that shouldn't penalize 16:18:51 s/defaults/defeats/ 16:19:03 Ok... let's be clear 16:19:18 simondodsley: YOU wouldn't have been ready if someobdy else didn't write the code to begin with 16:19:24 patrickeast: LVM is our reference in general 16:19:34 DuncanT: +1 16:19:43 kmartin: NOOOOO!!!!!!! 16:19:49 ok, so look as I said... if they get reviewed and land... then great 16:19:54 jgriffiths: and we appreciate all the hard work you put in 16:19:56 they're not blocked 16:19:56 patrickeast: Letting a vendor become the reference is what screwed us on replication the first time 16:19:58 let's move on 16:20:04 DuncanT: no no, sorry, i didn't mean that 16:20:05 simondodsley: it doesn't sound like it :) 16:20:16 DuncanT: just that typically we do start out with only a single impl... and things are ok 16:20:18 #link cinder review Inbox availabe at the bottom of: https://wiki.openstack.org/wiki/Cinder 16:20:19 seriously... issue closed, we should move on :) 16:20:37 jgriffith: thanks, sorry to rat-hole 16:20:45 patrickeast: not at all 16:20:56 patrickeast: and like I said, I don't think it should be blocked 16:21:02 jgriffith: So, the answer is they are out there and if we collectively choose to merge that is fine? 16:21:07 jgriffith: let's let the team decide with reviews 16:21:15 patrickeast: but I don't think anybody should NOT do something that's on the list 16:21:23 simondodsley: i think thats what the decision is 16:21:28 in other words priorities 16:21:31 asselin: That doesn't do what I want though 16:21:41 jgriffith: yea, totally understand 16:21:50 somebody form huawei here? 16:21:51 simondodsley: Thanks for putting it succinctly. :-) I suck at succinct. 16:21:57 DuncanT, let's discuss offline to adjust it 16:22:03 asselin: Thanks 16:22:16 I'm from Huawei 16:22:20 :) 16:22:23 wilson: hey... 16:22:30 hi 16:22:32 wilson: your hypermoto patch 16:22:37 yeah 16:22:50 I just rebased it 16:22:53 I have no issue if people review it and it merges 16:22:58 it's isolated to your driver 16:23:08 so to be clear to EVERYONE 16:23:15 on Monday we were in REALLY bad shape 16:23:16 thanks jgriffith 16:23:23 between the gate and outstanding patches 16:23:39 none of the mid and high priority changes were being reviewed 16:23:55 so jungleboyj and I talked and put a -2 on EVERYTHING that was low pri 16:24:11 so that people would focus on middle and high priority items (which they weren't) 16:24:37 gate resumed operation, mid and high pri items got attention, so now I'm not nearly as concerned about things 16:24:53 but I want to clarify... "things that are isolated" 16:25:06 the hypermoto patch falls in to that category 16:25:31 yeah 16:25:34 tbarron: given you had some choice comments for me and an ML posting I'm surprised I don't see anything from you on this list? 16:25:56 jgriffith: I had no choice comments for *you* or for any individuals 16:26:07 tbarron: I think you know what my point is 16:26:10 jgriffith: if one reads http://lists.openstack.org/pipermail/openstack-dev/2015-September/073398.html carefully, I point to a 16:26:14 tbarron: you have nothign to share here? 16:26:23 jgriffith: an issue that we could take up in Tokyo 16:26:49 tbarron: ok, last chance.. your patches... any requests, visibility you want to raise? 16:26:49 jgriffith: I think some interesting ideas from you and from geguileo are in that thread, also question be dhellman 16:26:54 reommened reading 16:27:17 jgriffith: I am very grateful to the core team for swarming on the patches in the low pri queue once 16:27:27 the higher prio stuff got handled 16:27:36 jgriffith: so, if we have isolated things that we'd like to get accepted, should we request in cinder channel or here in the meeting? 16:27:45 jgriffith: I have no quarrel with ;prioritization and don't mean to imply that 16:28:01 tbarron: You are welcome. :-) 16:28:03 angela-s: LOL 16:28:14 jgriffith: I know some of my squeaky-wheel behavior has been a PITA. 16:28:19 angela-s: I'm not opening development back up if that's where you're going :) 16:28:37 angela-s: I'm providing a compromise for people that have had work up for several weeks that didn't make it 16:28:55 jgriffith: no, we've had a couple patches that were only pending CI 16:29:12 angela-s: well, talk to your peers 16:29:21 jgriffith: ok 16:29:29 angela-s: Is CI passing now> 16:29:32 I'm trusting core members of this team are core members because they have good judgement 16:29:57 but I'll stress, the items on LP ARE THE PRIORITY!!! 16:30:13 jungleboyj: yes brocade CI is passing now 16:30:23 so now... are there any questions? 16:30:29 angela-s, was the recheck fixed in the Brocade CI, I think that was the last thing that had thingee concerned 16:30:45 BTW... you should all note that gate time is approximately 14 hours right now 16:30:52 jgriffith: it appears that L-3 items on LP are taken care of now. I mean they are being reviewed or merged 16:30:54 kmartin: yes,recheck is working and format of failed message is also fixed. 16:31:08 so even if you submit something "now" and it gets a +2/A it's not very likely that it's going to land anyway 16:31:17 jgriffith, that's pretty good, down from 24 on Monday :) 16:31:18 xyang1: for the most part 16:31:24 kmartin: it's early :) 16:31:46 so with that... 16:31:51 jgriffith: when does everything have to be merged? Is there a deadline for merging? 16:31:55 #topic open discussion 16:32:01 0000 UTC 16:32:09 is Sept 3 16:32:11 angela-s: Ping us with the reviews and we can take a look. 16:32:25 jungleboyj: ok, will do 16:32:28 in OpenStack world 16:33:18 So I'll say one more thing... thanks to everyone who stepped up this week; and especially quite a few folks from the day shift who were on the night shift with me last night :) 16:34:00 We got a great team! 16:34:09 There's a ton of hard work that went on, jungleboyj geguileo xyang1 hemna patrickeast etc 16:34:28 so let's get the release cut and focus on testing it 16:34:58 I have a question 16:35:07 jgriffith: Thank you for leading this up in Mike's absence. 16:35:17 Does patch https://review.openstack.org/#/c/202023/ have chance to be merged in L 16:35:28 Huawei hypermetro 16:35:41 wilson: my opinion is that the -2 should be removed 16:35:47 wilson: That was discussed earlier. 16:35:52 wilson: and if it gets reviewed and lands, then cool 16:35:53 jgriffith: Ooops, let me do that. 16:36:03 jungleboyj, lol 16:36:18 That will be great! 16:36:28 jgriffith: did you see that there is a FFE request on mailing list 16:36:30 Thanks :) 16:36:38 jgriffith: about this one: https://review.openstack.org/#/c/206923/ 16:36:40 Sorry, I'm missing a lot. Did we extend the deadline? 16:36:56 smcgmobile: NO 16:37:10 wilson: Done ... Will take a look at it today. 16:37:10 smcgmobile: we just said that we're not actively rejecting things 16:37:28 smcgmobile: and that core reviewers are empowered to use judgement 16:37:30 jgriffith: ok, cool 16:37:43 jgriffith, python-cinderclient release was on the agenda, but focus should be on the RC cut then the client? 16:37:43 smcgmobile: in reality based on gate time, what's in is in at this point 16:37:52 kmartin: Oh... good point!!! 16:37:58 jungleboyi: thanks! 16:38:03 cinderclient is part of the relase 16:38:20 if there are things there that need addressed I suggest folks get on it 16:38:24 xyang1: That one looks more invasive. 16:38:25 jgriffith: so I added that item. is there a new deadline for client now? 16:38:31 we have a little more time with that, but it's not as flexible as it used to be 16:38:46 xyang1: Good question. Don't want to mess that up again. 16:38:46 jungleboyj: the FFE one? ya, that is in the common code 16:38:50 xyang1: I don't have an exact date/time for you on that 16:39:09 There is also that one I pinged you about yesterday that is suspicious. 16:39:10 but I would say that we should propose a release next week and barring issues that should be our version for L 16:39:12 jgriffith: what about the dependency deadline this week? 16:39:22 xyang1: so that's slightly different IIRC 16:39:29 jgriffith: I saw a few clients get released today, not sure if there's a deadline 16:39:34 xyang1: that's more geared towards libs 16:39:42 jgriffith: ok 16:40:07 xyang1: yes, I checked with the release team last week, we requested a release and stated there may be one more 16:40:21 jgriffith: sounds good 16:40:29 xyang1: same with brick 16:40:44 jgriffith: ok 16:40:50 anything else? 16:41:09 If there are any other -2's I should clean up, just ping me. 16:41:24 jungleboyj: thanks! 16:41:31 jgriffith: one small anouncement from me 16:41:33 My pleasure. 16:41:44 jungleboyj: but to clarify if they're "-2 for freeze" :) 16:42:20 jgriffith: Right, those that are appropriate candidates to have it removed. 16:42:46 Wasn't an offer for free passes. :-) 16:42:59 e0ne: What's up? 16:43:00 we're going to move forward with API v2 testing in gates and disable v1 in dsvm jobs by default. any objections? I'm wating for tempest patch to be reviewd merged 16:43:22 jungleboyj: LOL 16:43:45 thingee wanted to remove v1 at all, but we're blocked by grenade jobs and openstack client 16:43:51 e0ne: I think it's about damn time 16:44:18 e0ne, +1 16:44:20 w00t 16:44:26 e0ne: I know we're going to find problems, but regardless that whole V1/V2 thing has drug on for WAAAAYYYY too long 16:44:30 e0ne: ++ 16:44:38 jgriffith, +1!! 16:45:36 just wanted to clarify that nobody don't think that it's bad time for such things 16:46:12 e0ne: works for me. 16:46:38 Gotta do it some time. 16:47:42 e0ne: wish it was earlier TBH, but tired of nothing ever being "done" 16:48:22 jgriffith: is was harder than I expect 16:48:23 this really should have been tried after L2 16:48:36 to give us time to fix issues and let cross project teams iron issues out as well. 16:48:47 but this is what we always say, and it never happens 16:49:01 hemna: agreed 16:49:05 hemna: +1 16:49:55 e0ne, everyone should be testing and fixing bugs now, so no time like the present 16:51:22 kmartin, jgriffith: may be we need to anounce bug triadge day after L-3? 16:51:42 e0ne: Not a bad idea. 16:53:12 e0ne: You want to bring that up with thingee when he gets back and see if we can plan something? 16:53:32 e0ne: Or put it on the agenda for next week maybe? 16:53:41 e0ne, good idea, maybe wait for the RC to be build. thingee usually has one during the RC. L-3 is over tomorrow 16:54:11 jungleboyj: I'll ask thingee and send mail to openstack-dev ML 16:54:15 kmartin: Has everyone else passed out from exhaustion? 16:54:18 ok... anything we can't chat about in #penstack-cinder at this point? 16:54:25 Nope. 16:54:33 alright, let's wrap it up 16:54:44 #endmeeting cinder