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