17:59:57 #startmeeting trove 17:59:58 Meeting started Wed Oct 29 17:59:57 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:02 The meeting name has been set to 'trove' 18:00:24 Giving folks a few minutes to get here. 18:00:25 ./ 18:00:29 o/ 18:00:34 o/ 18:01:16 o/ 18:01:48 Agenda at: 18:01:51 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:03:36 denis_makogon: around? 18:03:38 Looking at this agenda, I have a couple of comments. 18:03:55 SlickNik, sure 18:04:18 We had decided that folks should refrain from putting individual code reviews on the agenda. 18:04:55 SlickNik, it's not about code review, it's about making concrete decision how to fix certain bug 18:05:11 #link https://bugs.launchpad.net/trove/+bug/1220989 18:05:14 Launchpad bug 1220989 in trove "Instance in backup status can be deleted which leaves the backup in NEW/BUILD state" [Low,In progress] 18:06:01 denis_makogon: So why is the code review on the agenda? 18:07:15 Honestly, I'm still unclear on what's being brought up / proposed here. 18:07:24 SlickNik, there's no big difference if is not a LP link, since it's not a review request 18:07:52 You mention in the agenda that the review has a -2 from Auston for a design reason. 18:07:53 we have two ways for fixing this bug 18:07:55 o/ 18:08:00 So is there an alternative that you are proposing? 18:08:34 SlickNik, Auston had alternative, that is described at review comments 18:08:38 not on bug report 18:09:13 It appears during the discussion on https://bugs.launchpad.net/trove/+bug/1220989 ikhudoshyn and hubcap liked the idea to mark backups as FAILED to allow delete 18:09:14 Launchpad bug 1220989 in trove "Instance in backup status can be deleted which leaves the backup in NEW/BUILD state" [Low,In progress] 18:09:46 edmondk, correct, that's actually what i did 18:10:08 and Dennis is questioning Auston's -2 18:10:24 edmondk, i'm not questioning why -2 18:10:39 i'm here to discuss the proper way to fix given bug 18:10:44 Or we decide on a new fix gotcha 18:10:59 edmondk, thanks =) 18:11:13 my 2 cents... if the bug is fixed as described a bug report.. we shouldn't -2.. rather commnet on the bug if you disagree 18:11:38 vipul, sound reasonable 18:12:13 So, I'm saying that the folks involved in the review and design are yourself, amcrn and hub_cap. So it makes more seconds to talk with them on IRC to hash out a plan forward. 18:12:27 so, we have two approaches - marking all running backups as FAILED and allow to delete instance, or add similar MGMT API for reseting backups 18:12:47 Yeah agreed too much background knowledge required on this for us to come up with a solution in this meeting 18:12:58 more sense* 18:13:16 ok, i get that 18:13:57 for next meeting me hub_cup and amcrn will report about this topic 18:14:08 o/ 18:14:08 may I ask why it has to be at this meeting? 18:14:28 Why not just have it as part of the review? 18:14:41 It's a small design decision for one code review — do we really need to spend everyone's meeting time on it? 18:14:49 o/ 18:14:50 amrith, more eyes, more feedbacks =) 18:15:19 sorry for the fashionably late entrance 18:15:20 denis_makogon, by that logic I'd like to add each and every review (outstanding) to this meeing. 18:15:22 +1 to having it just be part of the review. 18:15:35 -1 to discussing review's at this meeting. 18:16:01 amrith, it's about design decision, but not reviewing code 18:16:04 +1-1=0 18:16:26 and design decisions can be discussed on IRC or in a code review. 18:16:49 ok 18:17:00 Okay, let's move on to the next item 18:17:21 This seems to be another review :) 18:17:59 same, design decision 18:19:36 are we going to discuss it or skip it due to previous comments? 18:19:57 I'm reading the item, and I'm not sure what the design decision here even is. 18:21:13 * amrith abstains since I'm an involved party on this review 18:21:15 It looks like amrith made some comments on the review and you said you'd look into the checks. 18:22:41 So I'm not sure what the agenda item is for. 18:23:02 there are two ways to fix given issue 18:23:13 we might need to choose suitable one 18:23:52 we can choose "early bird" - flexible framework that can handle different validation checks 18:24:15 or made same validation that we have to regular/full backup 18:24:51 denis_makogon: This is a bug-fix, I'm not sure we need to implement a different framework for it. 18:24:54 the first one looks good, but, as amrith said, came a bit early 18:25:13 But whatever the case, please use the review to figure this out. 18:25:52 ok 18:25:53 And if you do put an item in the meeting's agenda, it would be good to follow the "Guidelines for Agenda Items" 18:26:07 SlickNik, i did =) 18:26:40 if you have concerns about it, let's discuss if offline and proceed to the next item 18:27:06 we have two more topics to go 18:27:08 Just need the approaches inside the agenda item 18:27:21 so everyone doesn't have to go through all the patch notes and review 18:27:55 edmondk: +1, I'm not sure what the goal of the agenda item is, or what approaches are being advocated. 18:28:03 But let's move on in the interest of time. 18:28:21 if we're on to the third item, it looks like a review of an outline of a possible blueprint. 18:28:26 #topic https://gist.github.com/denismakogon/15561df6dc5ddc60ba74 18:28:48 so let's get a blueprint and then we can review it? 18:29:22 amrith, why can't we just discuss it and then file a BP ? 18:30:25 go right ahead. I just stated my opinion. Others already said they're not sure what the proposal is that we're going to discuss, but don't let me stop the discussion. 18:31:07 denis_makogon: Because this isn't in the BP format. I don't know what API implications this has. 18:31:35 It's also much easier to give feedback in gerrit, than in an ad-hoc manner in an IRC meeting. 18:31:43 SlickNik, there's no API implications, or modifications, it's just refactoring existing CLI 18:31:46 That was the purpose of moving to specs. 18:32:44 it's not a spec, it's just a small proposal that can be evaluated into the BP 18:33:02 just wanted to discuss it first before writing a spec 18:33:43 Are you proposing different actions based upon the different datastores 18:34:11 edmondk, yes, that's how clustering framework works 18:34:18 What happens if added another datastore that contains a new type. This doesn't seem very generic for trove 18:34:24 not just actions, possibly having different commands for each datastore 18:34:29 and it making the CLI very specific for specific types 18:35:19 that's the reason why i want to discuss it and find proper way to do what we need 18:35:23 I thought the goal of a database as a service is it is agnostic to the actual DB type 18:35:47 making the actual client be aware of types defeats that goal 18:35:56 how about something along the lines of 'trove cluster-add' 18:36:07 why do you need to differentiate add_shard vs. add_node 18:36:23 edmondk: +1 18:36:26 vipul, shard term is specific for mongodb 18:36:32 vipul: agreed, something like trove cluster-add or add-cluster is more generic and makes sense 18:36:35 I'm still unclear on how the CLI would know what datastore/cluster types are implemented by a provider 18:36:36 edmondk, i agree with it too 18:36:56 right.. the cli commands should be generic.. the user knows they are adding a shard or a node 18:37:06 vipul +1 18:37:09 based on the underlying datastore they are acting on 18:37:10 SlickNik, it doesn't know 18:37:56 wasn't the Clustering API supposed to be generic? 18:38:04 yes 18:38:07 so it appears that the issue is that add_shard is too mongo specific. then shouldn't we just fix that and make add_shard deprecated and change the API to scaleup-cluster 18:38:07 denis_makogon: If it doesn't know, then it's better to have something generic. 18:38:25 dougshelley66, it suppose to be, but we did what we did =) 18:38:36 what you are proposing is more like a wrapper on a non-generic API to make it appear generic 18:38:51 why have this veneer, why not fix the underlying issue if that's what you think it is. 18:39:02 or let's leave it as mongodb-add-shard 18:39:08 and cassandra-add-node 18:39:12 amrith, i'm just trying to find proper solution with help pof all of you 18:39:18 and the user knows what it is. 18:39:48 sounds like a perfect subject for a blueprint, if you ask me. 18:40:03 as edmondk said, as DBaaS Trove should stay agnostic to all supported databases 18:40:27 amrith, with changing an action - yes, completely agreed 18:40:39 If add_shard is already in the amrith mentioning deprecation is a good way to fix this and add something generic going forward 18:40:45 denis_makogon, it sounds like the guidance is to write a BP/spec that proposes a more generic solution for this 18:40:59 dougshelley66, agreed 18:41:16 I'd be open to deprecating add_shard in favor of a more generic action across clusters. 18:41:23 so, as i can see, there's no objection against changing action 18:41:38 denis_makogon, not here there isn't 18:41:43 denis_makogon, along the lines of what vipul proposed 18:41:53 but if there's a bp and it is fully reviewed, expect others to participate as well and there may be objections. 18:41:57 But I'd like to see this thought out as a BP, so we can call out the implications. 18:42:09 heck, I may change my mind and think it's a bad idea later after reading in detail what it entails. 18:42:54 sure, let's do this, i will try to assemble spec by the summit start and we'd be able to discuss it f2f and approve it right after Summit 18:43:05 using regular workflow 18:43:53 i'd try to bring Auston as initial reviewer for new spec 18:43:59 thanks 18:44:11 that's all 18:44:13 Sounds good — let's move on to the next topic. 18:44:43 in the interest of time. 18:45:06 #topic Allow users to retreive guest log files 18:45:13 This item is not for discussion here. 18:45:13 But, since I know that everyone reads the agenda, this was a shamless advertisement to get the word out to people to take a look at this review, and provide feedback since we may not have a meeting on Monday. It proposes a different approach than earlier proposals. 18:45:13 It would be good to have consensus on this before Iccha has a mentee. 18:45:23 Thanks 18:45:28 End of discussion. 18:45:29 you type fast 18:45:34 if you have questions, post them in the review. 18:45:47 Vipul, yes I do! 18:45:55 vipul, he has a secretary do it 18:46:07 That was fast. 18:46:08 i figured.. perks 18:46:18 #topic Open Discussion 18:46:19 hey secretary, you weren't to say that on IRC. 18:46:31 crap...blew it again 18:46:51 so who is going to be in paris? 18:47:02 me 18:47:02 paris: +1 18:47:06 o/ 18:47:07 o/ 18:47:08 moi aussi 18:47:20 Speaking of the summit 18:47:38 The design sessions are now published at: http://kilodesignsummit.sched.org/ 18:48:06 #link http://kilodesignsummit.sched.org/overview/type/trove#.VFE2WXWSzQo 18:48:42 i have question 18:49:04 are there any plans or schedule for meetup day? 18:49:34 denis_makogon: You mean the trove contributors meetup? 18:49:44 yes 18:50:08 o/ 18:50:59 There's not any plans set in stone - I know some folks are planning to have discussions around certain topics with some of the others. 18:51:35 It's more of an open discussion where folks can bring up things they want to talk about. 18:52:06 i get that 18:52:09 thanks 18:52:42 Anything else for open discussion? 18:52:49 if someone is interested i'd like to discuss how can we achieve deployment within multiple zones/regions 18:53:01 during Contribution meetup 18:54:10 also good question is cluster networking topology 18:54:39 denis_makogon, are they on etherpad? let people signup that way. 18:55:07 Thanks folks! 18:55:09 #endmeeting