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