18:00:51 <cp16net> #startmeeting trove 18:00:53 <openstack> Meeting started Wed Dec 2 18:00:51 2015 UTC and is due to finish in 60 minutes. The chair is cp16net. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:56 <openstack> The meeting name has been set to 'trove' 18:01:01 <vkmc> o/ 18:01:02 <cp16net> #topic rollcall 18:01:09 <peterstac> o/ 18:01:15 <cp16net> howdy trovers 18:01:16 <amrith> ./ 18:01:22 <imandhan> o/ 18:02:03 <pmalik_> ☺/ 18:03:04 <vkmc> pmalik_++ haha 18:03:51 <cp16net> nice 18:04:48 <atomic77> \-=O=-/ 18:05:01 <dougshelley66> o/ 18:05:17 <cp16net> #topic stats update 18:05:24 <cp16net> #link https://etherpad.openstack.org/p/trove-pulse-update 18:05:31 <cp16net> #link http://bit.ly/1VQyg00 18:06:24 <cp16net> we've had a drop off on the # of reviews i guess it was partly due to a holiday 18:06:44 <vgnbkr> o/ 18:06:55 <cp16net> on the otherside we have a big drop in open patches 18:07:10 <cp16net> i think this is due to cleaning up the backlog 18:07:20 <amrith> cp16net, yes, I went and abandoned a bunch of them over 4 months. 18:07:41 <cp16net> thanks amrith and slicknik for going over those :) 18:07:43 <atomic77> we're down from a peak of 104 to 75, that's great progress 18:07:58 <cp16net> atomic77: i agree thats awesome 18:08:06 <cp16net> only 75 more to go :-P 18:08:21 <amrith> cp16net, I'm concerned at the merge rate. 18:08:27 <amrith> it is too low. 18:08:38 <amrith> we can't hope (pray) to merge everything at deadline-1 day 18:09:03 <cp16net> yeah i'll get to that in a bit 18:09:14 <cp16net> anything else on the reviews? 18:09:20 <atomic77> although this is why i was hoping we'd get the outstanding specs approved, as those will spawn a number of patchsets that will bring our backlog up again 18:09:50 <atomic77> still 7 out there (I think we merged two from last week) 18:09:59 <mvandijk> ./ 18:11:13 <cp16net> atomic77: yeah i have a topic of spec reviews we can bring those up 18:11:24 <cp16net> #topic past action items 18:11:27 <atomic77> ah cool 18:11:57 <cp16net> thanks for running the meeting in my absence last week peterstac 18:11:59 <cp16net> :) 18:12:06 <peterstac> cp16net, np 18:12:40 <cp16net> amrith: thanks for scrubing the reviews 18:12:47 <cp16net> looks like that helped a ton 18:14:11 <dougshelley66> definitely - thanks...All the reviews fit in one page now :) 18:14:12 <cp16net> looks like the other action items are covered in the topics i have 18:14:32 <cp16net> dougshelley66: depending on your resolution :-P 18:14:46 <dougshelley66> cp16net right...you need a bigger monitor 18:15:05 <cp16net> #action M1 branch cut 18:15:14 <cp16net> doh... 18:15:31 <cp16net> #topic M1 branch cut 18:15:50 <cp16net> So the cut deadline for M1 is tomorrow Dec 3rd 18:16:03 <cp16net> we still have a few things to approve 18:16:07 <cp16net> and to push 18:16:23 <cp16net> one thing i'm hearing is the final patches for reno support 18:16:56 <cp16net> i'll push the other patches that are needed and we need to get those approved asap 18:17:05 <cp16net> #action push the final reno patches 18:17:13 <cp16net> #action cp16net push the final reno patches 18:17:23 * cp16net doing terrible with #actions today... 18:19:03 <cp16net> as far os the specs 18:19:24 <cp16net> i see 8 reviews open for them 18:19:48 <cp16net> lets get these looked over by the end of the week 18:20:24 <cp16net> since these are in a different repo its ok to approve after M1 is cut 18:21:09 <cp16net> but lets put a deadline by EOD on Dec 4th for specs 18:21:28 <cp16net> #link https://review.openstack.org/#/q/status:open+project:openstack/trove-specs,n,z 18:22:49 <cp16net> if it doesnt get approved we'll talk about it for post approval 18:22:53 <cp16net> sound good? 18:23:53 <johnma> cp16net: sounds good to me 18:24:52 <cp16net> i dont think i have anything else on that topic right now 18:25:07 <dougshelley66> cp16net just to make sure i understand - you are proposing that everything requiring 18:25:17 <dougshelley66> a spec for mitaka is to be merged by dec 4th? 18:25:36 <cp16net> yes that is the idea 18:25:38 <dougshelley66> and after that we will manage any incoming specs on an exception basis? 18:26:11 <cp16net> so that we have a good idea of what is to come throughout Mitaka 18:26:26 <dougshelley66> makes sense to me 18:26:28 <cp16net> and mainly this is to help the rush at the last minute 18:26:41 <atomic77> so we should all make a push to review the outstanding specs by the end of the week 18:26:58 <cp16net> right 18:26:58 <atomic77> and our fearless +2's deliver a final verdict? :) 18:28:20 <cp16net> what do others think about making M-3 a deadline for the bp implementations of specs? 18:28:31 <cp16net> then m-4 would be for bug fixes 18:30:04 <cp16net> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule 18:30:44 <dougshelley66> cp16net i'm good with that 18:30:50 <cp16net> so the end of february have all the specs code complete and merged 18:31:13 <cp16net> i'd like to say specs delivered by M-2 in a review 18:31:21 <atomic77> seems reasonable 18:31:47 <cp16net> gives some room to wiggle there 18:32:25 <cp16net> i dont see many people commenting on this but i dont see anyone objecting 18:32:30 <atomic77> we definitely don't want to be playing gate roulette again at the end of the cycle 18:32:41 <atomic77> so makes sense to be a bit ambitious even if we do get held up a bit 18:32:55 <cp16net> i'll bring it up again next time to give others time to think about it or comment again 18:32:57 <imandhan> sounds good to me - nice to have these deadlines set 18:33:31 <cp16net> #action cp16net bring up M2 code complete specs and M3 merge specs 18:34:14 <cp16net> with that said i think i'll open it up for others 18:34:26 <cp16net> #topic Open Discussion 18:34:33 <pmalik_> Speaking of gate roulette, could we possibly get this in? It should help to aliviate some of those random failures. Thx. https://review.openstack.org/#/c/248421/ 18:34:46 <vkmc> I'd be nice to have some more time for people to finish their specs after this announcement 18:34:51 <vkmc> I mean, Dec 4th is Friday 18:35:11 <amrith> pmalik_, I was going to +1 it but it failed gate ;) 18:35:15 <vkmc> and there are a lot of holidays in the middle 18:35:21 <tellesnobrega> +1 vkmc 18:35:37 <tellesnobrega> we could give till next friday 18:35:38 <vkmc> not much, maybe push it to late next week 18:35:51 <pmalik_> amrith I think the failure there is unrelated, but sure, let's wait for the second run... 18:36:23 <cp16net> vkmc: alright i'm good with next friday 18:36:24 <atomic77> maybe we can make the deadline for the specs which have had time to marinate 18:36:25 <amrith> vkmc, are there specs that you have in mind that aren't already in review? 18:36:36 * atomic77 prepares the spec BBQ 18:36:38 <cp16net> Dec 11th for spec completion 18:36:40 <amrith> same question for others ... 18:36:48 <atomic77> and next week for 'new' ones? 18:36:53 <amrith> are there specs that you'd like to have in m-release which aren't you in review? 18:37:19 <vkmc> amrith, there are yes 18:37:37 <vkmc> (I'm talking for me here) 18:37:43 <amrith> ok, I was wondering how many of these there are likely to be. 18:37:58 <amrith> I ask knowing that I may also have one, but this Friday is fine for me. 18:38:01 <vkmc> and I know tellesnobrega is working on a spec as well 18:38:04 <tellesnobrega> i just put today the spec for removing migrations 18:38:09 <cp16net> it doesnt sound like many 18:38:15 <tellesnobrega> removing downgrade from migraitons 18:38:50 <cp16net> which i was saying its fine to have them after this deadline but lets get the 8 that i see now worked on by this friday 18:38:52 <tellesnobrega> seems a consent that we need to shoot an email from mailing list to figure out if anyone is using this 18:39:08 <vkmc> tellesnobrega++ 18:39:10 <amrith> maybe to the operators list, not the dev mailing list. 18:39:24 <tellesnobrega> amrith, sure 18:39:36 <cp16net> and then we can at least have a majority of them merged 18:39:58 <amrith> but before you do that, you may want to read my comments on the spec. there appears to be no requirement to remove existing downgrades (although that's what neutron did). 18:40:00 <tellesnobrega> sounds like a good plan 18:40:12 <amrith> the only requirement is that we don't accept new ones and we document how to restore the database to an old state. 18:40:17 <amrith> per the cross-project spec. 18:40:37 <tellesnobrega> amrith, sure, i will take a look into that 18:40:47 <cp16net> i have one other question i wanted to bring up 18:40:48 <amrith> so, a simple, low disruption solution is that we just don't accept new migrations that include downgrades. 18:41:25 <amrith> <EOF> 18:41:45 <tellesnobrega> amrith, makes sense, i will take a deeper look into that and if necessary i will send the email 18:41:55 <amrith> tellesnobrega, thx 18:42:04 <tellesnobrega> amrith, np 18:42:07 <cp16net> i think most of the downgrades we have are not tested at all 18:42:38 <tellesnobrega> cp16net, there is only one test, checks if the migration files have downgrades 18:43:27 <cp16net> yeah but i'm sure they will screw things up if they run at all 18:43:44 <amrith> so you are advocating just getting rid fo them cp16net 18:43:51 <tellesnobrega> cp16net, probably 18:44:15 <cp16net> i'm on the fence about removing them all 18:44:22 <tellesnobrega> amrith, i think it is the best option, if downgrades are not necessary we can't force this test 18:44:33 <cp16net> my thought is if the code is not tested should we have the code there at all? 18:44:39 <amrith> cp16net, will an answer from oeprators (or as was the case in other projects, no answer) change your mind? 18:44:55 <cp16net> amrith: for sure 18:45:17 <cp16net> if someone really needs a downgrade then its something we should concider 18:45:36 <tellesnobrega> otherwise i say kill them all 18:45:44 <cp16net> but from my xp i dont know of any situation where i've decided to downgrade a system 18:46:04 <peterstac> cp16net, plus it can be dangerous to downgrade/upgrade 18:46:13 <cp16net> yeah its destructive 18:46:20 <peterstac> you think you'd be back at the same point. but you're probably not 18:46:21 <tellesnobrega> peterstac, that's the whole point 18:46:23 <amrith> in that case, let's dispense with the email to the list and just do it? 18:46:30 <cp16net> especially when its changing 1000s of records in the db 18:46:49 <tellesnobrega> amrith, i think we can email, wait a day or two 18:46:53 <tellesnobrega> and them move on with this 18:46:57 <tellesnobrega> what you guys say? 18:47:03 <cp16net> sounds good to me tellesnobrega 18:47:13 <amrith> fine, I +2'ed it. if you can get someone else to +2/+1 it, you are golden. 18:47:27 <tellesnobrega> awesome 18:47:35 <cp16net> tellesnobrega: will you send an email? 18:47:42 <tellesnobrega> sure 18:47:45 <cp16net> thanks 18:47:55 <tellesnobrega> can put that as an action item for me 18:48:10 <cp16net> #action tellesnobrega send an email about removing downgrades to operators 18:48:19 <tellesnobrega> great 18:48:35 <cp16net> ok so i had one other thing 18:48:53 <cp16net> there was some talk about the trove client versioning 18:49:32 <cp16net> we made a change for exceptions being raised in the client and made a minor version with it when it should have been a major version 18:50:27 <cp16net> is this still a problem for the kilo and liberty branches? 18:50:31 <cp16net> anyone aware? 18:51:00 <amrith> I don't have enough context. is there something on ML or in IRC scrollback? 18:51:14 <cp16net> there was a ML email about this 18:51:26 * amrith runs to consult with Outlook 18:52:02 <cp16net> http://lists.openstack.org/pipermail/openstack-dev/2015-November/079702.html 18:52:15 <cp16net> i think this still needs to be addressed 18:52:25 <cp16net> it shouldnt be hard to do 18:52:38 <cp16net> make a revert commit of the exception change 18:53:15 <cp16net> release new minor version 1.5.0 18:53:37 <cp16net> put the commit back 18:53:42 <cp16net> release 2.0.0 18:53:45 * amrith scratches head ... wonders how that would work. 18:54:30 <cp16net> need to make sure its still an issue with the kilo/liberty branches tho 18:54:41 <cp16net> i think they are working now so i might not be an issue 18:54:51 <peterstac> cp16net, I think the main problem stemmed from the fact that a server test was checking a client exception 18:55:20 <cp16net> #action follow up on the trove client version issue on killo/liberty branches 18:55:31 <cp16net> #action cp16net follow up on the trove client version issue on killo/liberty branches 18:55:47 <cp16net> peterstac: yea i think so 18:55:56 <cp16net> anyone have anything else? 18:56:25 <cp16net> oh... trove midcycle rsvp 18:56:27 <cp16net> #link https://etherpad.openstack.org/p/mitaka-trove-midcycle-rsvp 18:56:31 <amrith> cp16net, wouldn't that mean 1.5.0 is inconsistent with 1.4.0? 18:56:50 <amrith> shouldn't we just release 2.0.0 and mark 1.4.0 as bad? 18:56:51 <cp16net> amrith: it could be 1.4.1 18:56:53 <amrith> instead? 18:57:32 <amrith> anyway, you have the #action ... 18:57:46 <amrith> just an option, don't bother releasing 1.5.0, just mark the current (1.4.0) as bad. 18:57:48 <cp16net> the other branches should have requirements of troveclient<2.0.0 18:58:10 <amrith> or !=1.4.0,... 18:58:47 <cp16net> i think it would be missing some of the changes tho 18:59:01 <amrith> we seem kind of light on the rsvp's ... 18:59:03 <cp16net> between 1.3 and 1.4 there was a while 18:59:08 <cp16net> yeah we are 18:59:35 <cp16net> alright i think its about time 18:59:42 <amrith> thanks cp16net 18:59:46 <amrith> have good one ... 18:59:46 <cp16net> thanks everyone 18:59:50 <cp16net> #endmeeting