20:02:41 <SlickNik> #startmeeting trove
20:02:42 <openstack> Meeting started Wed Aug 28 20:02:41 2013 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:47 <openstack> The meeting name has been set to 'trove'
20:02:59 <kevinconway> \o/
20:03:04 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
20:03:13 <imsplitbit> o/
20:03:15 <pdmars> o/
20:03:18 <esp> o/
20:03:21 <robertmyers> o/
20:03:38 <SlickNik> Feel free to add items to the agenda if you want to bring them up.
20:03:53 <cp16net> o^/
20:04:01 <ashestakov> o/
20:04:08 <vipul> I think the agenda is mostly from last week btw
20:04:10 <SlickNik> #topic action items
20:04:32 <SlickNik> yeah, I left some of the items in, in case people had updates.
20:04:42 <SlickNik> If not, I'm going to remove them and move right along.
20:04:58 <SlickNik> imsplitbit: you're up on the first one
20:05:05 <imsplitbit> #link https://review.openstack.org/#/q/status:open+project:openstack/trove+branch:master+topic:clustering,n,z
20:05:07 <SlickNik> 1.	imsplitbit to push up cluster api to feature branch
20:05:10 <imsplitbit> BAM
20:05:33 <vipul> nice
20:05:35 <SlickNik> Awesome, nice work. Thanks for pushing that up.
20:05:38 <imsplitbit> lesson learned from that...
20:05:47 <imsplitbit> the command is "git review -t topic"
20:05:53 <imsplitbit> if you make a change and need to resubmit
20:05:57 <imsplitbit> you can't just do "git review"
20:06:04 <imsplitbit> it doesn't store the topic local
20:06:19 <vipul> because it has a dependency?
20:06:29 <imsplitbit> not sure yet
20:06:38 <imsplitbit> but if you do git review it pulls it from the topic
20:06:45 <imsplitbit> you have to do git review -t topic EVERY time
20:06:50 <imsplitbit> any change
20:06:57 <SlickNik> #info The command is "git review -t topic" if you make a change and need to resubmit. You can't just do "git review" as it doesn't store the topic local
20:07:01 <imsplitbit> so just an FYI for the team if
20:07:09 <imsplitbit> like that
20:07:18 <SlickNik> Sounds good.
20:07:42 <SlickNik> Next we have: hub_cap to find out what happens w/ feature based reviews that land after FF
20:07:49 <imsplitbit> he's flying
20:07:59 <SlickNik> I'm not sure of that, so I'm going to re-action it to remind us next week.
20:08:08 <datsun180b> and boy i bet his arms are tired
20:08:11 <imsplitbit> omg
20:08:17 <imsplitbit> I knew someone was gonna say it
20:08:19 <SlickNik> #action hub_cap to find out what happens w/ feature based reviews that land after FF
20:08:21 <SlickNik> heh
20:08:25 <SlickNik> never fails. :)
20:08:48 <SlickNik> Next one is mine: SlickNik update devstack review to add role to default devstack users.
20:09:38 <SlickNik> I was looking into this a bit more, and it seemed like other OS component do things differently.
20:10:00 <SlickNik> eg. neutron creates a _separate_ user like radmin and gives that user the role.
20:10:16 <SlickNik> So I'm still trying to figure out what the right thing to do here is.
20:11:00 <isviridov_> the same for heat user
20:11:29 <vipul> why don't we just create a user and give it the trove role? woudl they object?
20:11:38 <SlickNik> I've decided, that it's best that I leave the current devstack patch as is (it has gotten positive reviews so far, and I don't want to jinx it) and do this work later as part of another change-set.
20:11:59 <SlickNik> vipul: that's what we're doing right now, and I haven't heard any objections.
20:12:08 <SlickNik> We were talking about this as an optimization.
20:12:12 <vipul> ok..
20:12:24 <vipul> sound good to me
20:12:37 <SlickNik> okay, that's all I had to say about that.
20:12:53 <SlickNik> gonna re-action to do some more digging/investigation here.
20:13:31 <SlickNik> #action: SlickNik to leave current patch as is and investigate adding trove role to default devstack users in another patch.
20:13:40 <SlickNik> You're up next datsun180b
20:13:51 <SlickNik> * datsun180b to do pull request on phase one of Trove Conductor
20:14:33 <datsun180b> almost there--got the daemon built, just need to tune it in right. supplanting the GA to feed Conductor instead of writing the the DB itself was straightforward.
20:14:37 <datsun180b> no commit yet, but soon
20:14:54 <KennethWilke> weee
20:15:06 <datsun180b> reaction me if you please
20:15:07 <SlickNik> sounds good, looking forward to the commit. Want to re-action it for next week?
20:15:28 <datsun180b> that's a yes
20:15:42 <SlickNik> #action datsun180b to do pull request on phase one of Trove Conductor
20:15:47 <SlickNik> moving on
20:15:58 <SlickNik> * Find json style guide vipul hub_cap grapex
20:16:09 <vipul> so since the other two are out..
20:16:20 <vipul> it's all over the place.. camelCase vs underscore
20:16:24 <vipul> in openstack APIs that is
20:16:25 <vipul> https://lists.launchpad.net/openstack/msg23779.html
20:16:37 <vipul> Someone tried to point this out.. but went nowhere
20:16:56 <konetzed> we we can fix it on our project at least
20:16:58 <SlickNik> That makes me sad :(
20:17:01 <imsplitbit> yeah
20:17:05 <imsplitbit> it makes me super sad
20:17:13 <vipul> I think it makes sense to do it v2
20:17:15 <SlickNik> Yes, we should pick a style for us and keep to it.
20:17:24 <amytron> agreed
20:17:28 <KennethWilke> +1
20:17:29 <konetzed> maybe we can have a trickle up effect
20:17:31 <kevinconway> vipul: most JS guides suggest camel
20:17:32 <imsplitbit> I agree 100%
20:17:40 <imsplitbit> I'm fine with either
20:17:46 <imsplitbit> I would just like to see consistency
20:17:54 <konetzed> i dont care i just want something consistant
20:17:58 <vipul> javascript prefers camelcase.. python is underscore.. is what i see
20:18:04 <cp16net> i recall talks at the summit over this but nothing was ever decided on
20:18:11 <kevinconway> our variable don't have to match our API output
20:18:12 <KennethWilke> hungarian notation it is!
20:18:14 <SlickNik> Yeah same here. I don't have a preference as long as we're consistent. Let me action this for the team to discuss with hub_cap and grapex  when they get back?
20:18:23 <datsun180b> probably the best idea
20:18:40 <vipul> yea, let's pick something for v2 (whenever that happens)
20:18:44 <kevinconway> i think we should run jslint over trove and see what happens
20:19:20 <datsun180b> what'll happen is there will be a kevin-shaped crater in your seat
20:19:26 <SlickNik> #action team needs to discuss and come up with a consistent JSON notation across API
20:19:57 <SlickNik> #action ^^hub_cap grapex vipul SlickNik
20:20:04 <konetzed> SlickNik: you think that will be decided by next meeting?
20:20:10 <esp> datsun180b: lol
20:20:24 <datsun180b> the decision can happen quickly, but implementing it completely likely won't
20:20:42 <konetzed> datsun180b: thats a given :D
20:20:59 <konetzed> but sooner decision is mad the sooner we stop taking on tech debt
20:21:06 <konetzed> /mad/made
20:21:13 <amytron> konetzed: +1
20:21:15 <SlickNik> konetzed: I'd sure hope so.
20:21:18 <imsplitbit> +1
20:21:25 <esp> I'm guessing there will be client and server side validation?
20:21:37 <kevinconway> i think we should modify all old commits to make it look like we always complied with the style we choose
20:22:03 <esp> vipul: yt?
20:22:22 <SlickNik> kevinconway: let's talk about that offline in trove once hub_cap and grapex are around.
20:22:39 <vipul> ping
20:22:47 <SlickNik> s/trove/#openstack-trove
20:23:06 <SlickNik> Okay, moving on.
20:23:42 <SlickNik> #topic Automated Backups Design Update
20:23:47 <cp16net> joy
20:24:05 <SlickNik> cp16net: take it away
20:24:06 <cp16net> so we talked last week with a few people about the api
20:24:42 <cp16net> and i think we came to the realization that there is lots of metadata and not all of it makes sense for the first pass
20:25:30 <cp16net> so we changed the sturcture around a bit to accomodate the task_metadata
20:25:51 <cp16net> #link https://wiki.openstack.org/wiki/Trove/scheduled-tasks
20:26:11 <cp16net> we moved the retention period andnotifications
20:26:54 <cp16net> with that being said i sounded like the overview of the api was accecpted by those that were involved in the chat
20:27:03 <cp16net> i dont recall who that all the was right now
20:27:13 <SlickNik> Thanks for the wiki page updates and the link cp16net
20:27:33 <cp16net> i've worked on creating the api and database model for this
20:27:43 <cp16net> i'll add it to the wiki so that its documented as well
20:28:02 <cp16net> i have not made much more progress
20:28:07 <SlickNik> okay, sounds good.
20:28:09 <kevinconway> cp16net: some of your params say options
20:28:14 <kevinconway> as in you don't have to pass them in the request?
20:28:33 <kevinconway> *optional
20:28:34 <cp16net> #action cp16net add the database model to the scheduled_task wiki
20:29:07 <cp16net> kevinconway: i am not sure which ones you are speaking of
20:29:18 <kevinconway> notifications: - optional
20:29:19 <cp16net> description?
20:29:25 <kevinconway> notifications: - optional
20:29:27 <kevinconway> oops
20:29:30 <kevinconway> same pasta
20:29:32 <cp16net> ahh yea
20:29:33 <kevinconway> but yeah
20:29:37 <cp16net> that was the idea
20:29:46 <kevinconway> does our api validation allow for optional params?
20:29:59 <juice> yes
20:30:00 <SlickNik> I think it does.
20:30:10 <imsplitbit> yuppers
20:30:20 <SlickNik> okay, thanks for the update cp16net
20:30:22 <cp16net> well you dont validate it then its all optional right?
20:30:24 <cp16net> :-P
20:30:46 <vipul> I can see a whole bunch of stuff around notifications
20:30:50 <cp16net> but thats something to look at kevinconway
20:30:53 <vipul> like notification type..
20:31:03 <vipul> but maybe we don't want to worry about that now
20:31:07 <cp16net> vipul: yeah it could snowball that way
20:31:22 <SlickNik> #action Team to go through the wiki changes at https://wiki.openstack.org/wiki/Trove/scheduled-tasks and give cp16net feedback
20:31:35 <cp16net> SlickNik: thanks plz do!
20:31:38 <cp16net> :)
20:31:56 <SlickNik> Let's move on for now.
20:32:04 <cp16net> let me know if anyone wants to chat during the week or anything about it
20:32:17 <vipul> looks good cp16net
20:32:21 <SlickNik> #topic Clustering API update
20:32:26 <cp16net> ty sir
20:32:45 <imsplitbit> models and views are done
20:33:00 <imsplitbit> I'm in the middle of making the create call then I'll submit
20:33:10 <imsplitbit> this is API only
20:33:18 <SlickNik> awesome, thanks imsplitbit.
20:33:28 <vipul> imsplitbit: do we want to start serioiusly looking at some of this for the purposes of merging now? or is that something we want to hold off on
20:33:58 <imsplitbit> well I would love feedback on the existing code for clustertypes
20:34:15 <imsplitbit> but with the feature freeze for havana next week
20:34:16 <cp16net> vipul: i thought this was going to wait until I
20:34:20 <imsplitbit> it makes sense to give feedback
20:34:24 <imsplitbit> but not merge
20:34:28 <cp16net> yeah
20:34:34 <vipul> cp16net: Ok just checking..
20:34:43 <vipul> yea probably no new api's in H
20:34:48 <cp16net> hub_cap mentioned that last weeke
20:35:09 <cp16net> err week before
20:35:10 <imsplitbit> and last week too
20:35:16 <SlickNik> Waiting till I for this seems prudent.
20:35:16 <imsplitbit> :)
20:35:29 <cp16net> tru
20:35:30 <imsplitbit> agree
20:35:33 <SlickNik> Any more questions / shall we move on?
20:35:36 <vipul> ok maybe i wasn't paying attention :P
20:35:40 <imsplitbit> moving on :)
20:35:48 <SlickNik> #topic Flavors per Service Type Update
20:35:57 <SlickNik> Looks like there's a review for this up
20:36:12 <cp16net> link?
20:36:15 <vipul> I believe it's still in Draft
20:36:26 <vipul> don't think the author is here.. SushilKM
20:36:52 <vipul> So he's got some tests to write, and he'll make it public
20:36:54 <SlickNik> Okay, it's still work in progress then.
20:36:55 <vipul> I've reviewed it
20:37:04 <vipul> but it's coming along
20:37:14 <cp16net> ok
20:37:24 <vipul> there are a couple of things that stem from it
20:37:31 <vipul> 1. manage flavors through mgmt api..
20:37:43 <vipul> 2. restrict which flavor can be booted per service_type
20:37:53 <vipul> 3. filter 'flavor list' by service type
20:38:14 <vipul> I've seen work for 1&2
20:38:50 <cp16net> bp?
20:39:09 <vipul> https://blueprints.launchpad.net/trove/+spec/service-type-filter-on-flavors
20:39:15 <SlickNik> #link https://blueprints.launchpad.net/trove/+spec/service-type-filter-on-flavors
20:39:30 <SlickNik> Thanks for the update vipul.
20:39:40 <isviridov_> Does #link https://review.openstack.org/#/c/43741/ work for you?
20:40:00 <cp16net> nope
20:40:06 <cp16net> all the links are broken
20:40:35 <SlickNik> I think that was the draft vipul was talking about.
20:40:49 <SlickNik> It's still WIP, as he mentioned.
20:40:56 <SlickNik> So let's move on to the next topic.
20:41:14 <SlickNik> #topic Trove Conductor Update
20:41:16 <demorris> vipul: so is this similar to what I submitted for types/versions?
20:41:28 <SlickNik> Skipping this one since datsun180b already gave an update about it.
20:41:34 <SlickNik> (Thanks!)
20:41:39 <vipul> demorris: kinda... although there is no explicit service_type api
20:41:41 <cp16net> ok i would like some more info on this :)
20:41:47 <datsun180b> that was easy
20:42:00 <SlickNik> datsun180b: anything else to add or should we move on?
20:42:01 <vipul> demorris: the requirement is to be able to define Nova flavors per Trove service type
20:42:09 <ashestakov> hey guys
20:42:12 <ashestakov> want to discuss this one https://wiki.openstack.org/wiki/Trove/trove-versions-types
20:42:12 <datsun180b> nothing relevant
20:42:26 <SlickNik> #topic Open Discussion
20:42:33 <ashestakov> i suggests add support of dbms version select on instance create
20:42:35 <demorris> vipul: hmm what does that mean exactly
20:42:36 <vipul> ashestakov: good timing you got demorris here
20:42:44 <demorris> sweet
20:42:47 <demorris> yeah, lets discuss
20:43:14 <ashestakov> maybe we can eliminate service_type percona and use percona as version on mysql
20:43:14 <ashestakov> for example [oracle-mysql-5.1.69, oracle-mysql-5.5.32, percona-mysql-5.5.11, percona-mysql-5.6.23, mariadb-5.5.18]
20:43:28 <ashestakov> on instance creation should be possible to select service_type and dbms_version from the list
20:43:58 <vipul> ashestakov: I'm generally Ok with that.. we need to consider backwards compatibility though
20:44:04 <demorris> the model I used was the name was DB + Major Version and then full version in the list
20:44:18 <demorris> where it could be N+1 depending on how many versions you actually support
20:44:28 <esp> ashestakov: I think I already have a bug for that.
20:45:10 <esp> #link https://bugs.launchpad.net/trove/+bug/1212027
20:45:21 <ashestakov> i think to each dbms version need map package name and version
20:45:47 <ashestakov> which will be used by GA for install
20:46:02 <vipul> I don't know if a minor version is necessary
20:46:02 <ashestakov> and eliminate mysql_pkg option
20:46:40 <demorris> its is for when you want to communicate updates
20:47:09 <vipul> right i meant it's shouldn't be necessary as a top level 'type'
20:47:11 <ashestakov> vipul: if new minor version of mysql will aailable, how to check what you use now and how
20:47:26 <vipul> ashestakov: trove should upgrade it for you automatically
20:47:35 <vipul> you as a user only care that you want mysql 5.5
20:47:45 <vipul> not that you want 5.5.29 or 5.5.18
20:48:01 <ashestakov> if user dont want to upgrade?
20:48:09 <ashestakov> like in amazon rds, it is optional
20:48:10 <cp16net> yeah i think the minor version is a little meticulous
20:48:12 <vipul> that can be a maitenance windoe thing
20:48:27 <vipul> if they choose not to provide a upgrade window.. we choose not to provide upgrades
20:48:30 <demorris> right, so this would be dependent per operator
20:48:37 <kevinconway> seems like minor could actually be major depending on the version scheme used by the dbms
20:48:41 <cp16net> trove doesnt update automatically now
20:48:58 <vipul> cp16net: right, but at some point it will
20:49:02 <cp16net> right
20:49:02 <demorris> you may decide that you want to update automatically or have it be user controlled (due to dbms restarts)
20:49:12 <ashestakov> when will multiverson support, the next step will upgrade i think
20:49:19 <demorris> you may decide that you want to support 10-20 previous versions or just one
20:49:48 <vipul> seems like when you upgrade.. you would want to go to the latest minor version the deployer has set
20:50:13 <demorris> correct, but there could be cases where you don't
20:50:23 <vipul> whether it's manual or automatic.. is there value in allowing users to pick the minor..
20:50:28 <demorris> I actually would not want to support more than one, but I think the API should allow it
20:50:36 <konetzed> wait, you sometimes dont want that, if your on 5.1 you dont want to go to 5.1
20:50:39 <konetzed> 5.5
20:50:45 <vipul> that's different
20:50:50 <vipul> i mean within 5.1
20:50:54 <konetzed> your talking minor numbers
20:50:59 <SlickNik> konetzed: that's major version
20:50:59 <konetzed> major.minor.rev
20:51:09 <vipul> oh
20:51:11 <vipul> fine :P
20:51:12 <vipul> rev
20:51:17 <kevinconway> konetzed: assuming the devs are using a real versioning scheme
20:51:29 <konetzed> well thats the way i have always seen it so im sorry i was way confused
20:51:40 <cp16net> ashestakov: so you are proposing that these service_types be in the service catalog?
20:51:46 <kevinconway> in my mind that's how it *should* be
20:51:49 <cp16net> ashestakov: that includes the type and version?
20:52:05 <demorris> guys I have to run to catch a bus, but I want to keep discussing this.
20:52:05 <isviridov_> According to #link http://dev.mysql.com/doc/refman/5.1/en/upgrading.html update from 5.1 to 5.5 also needs 5.2, 5.3 ...
20:52:24 <demorris> I will assume that y'all will keep digging on this - https://wiki.openstack.org/wiki/Trove/trove-versions-types
20:52:24 <kevinconway> demorris: i don't think the folks on the bus will know what you're talking about
20:52:41 <demorris> kevinconway: correct, I'll keep it to myself
20:52:43 <demorris> :)
20:52:45 <isviridov_> )
20:52:47 <vipul> lol
20:53:09 <ashestakov> cp16net: i propose to add possibility to select service_type and dbms_version
20:53:14 <vipul> isviridov_: I assume 5.1 to 5.5 will be something like 'restore from a backup'
20:53:17 <demorris> anyway, just beat up my blueprint and let me know
20:53:20 <SlickNik> so it seems like this needs a longer discussion
20:53:29 <SlickNik> And now might not be the best time to discuss it.
20:53:51 <konetzed> vipul: depends on the backup probably need a mysql dump
20:53:57 <SlickNik> ashestakov: Can we set up a meeting to discuss this at a convenient time for interested parties?
20:53:58 <demorris> offline is okay, i think the list is a good place for this
20:54:10 <demorris> I'd like to see y'all discussing BP's on the list more :)
20:54:15 <ashestakov> SlickNik: sure, when?
20:54:15 <cp16net> i'm not sure putting all the versions in the catalog makes sense
20:54:21 <demorris> later
20:54:46 <vipul> konetzed: Yea, which might be something we'll have to allow i am assuming..
20:54:52 <cp16net> tomorrow?
20:55:05 <vipul> works for me
20:55:06 <SlickNik> Are people good with discussing this on the openstack-dev list?
20:55:13 <konetzed> vipul: yea i think we will need the ablity to export (mysql dump) and import (mysql restore) a database
20:55:17 <SlickNik> Or meeting tomorrow?
20:55:24 <SlickNik> Either would work.
20:55:46 <vipul> btw.. i didn't see any of arborism's emails
20:55:59 <SlickNik> ashestakov: Your preference. Either tomorrow, or offline on openstack-dev.
20:56:00 <cp16net> or mine :(
20:56:00 <vipul> i saw a reply from imsplitbit but the original email just never showed up
20:56:04 <ashestakov> SlickNik: will hub_cap available tomorrow?
20:56:26 <cp16net> ashestakov: yea he will be back
20:56:26 <SlickNik> ashestakov: Not sure. Rackers?
20:56:35 <ashestakov> SlickNik: i think better on meeting
20:56:38 <cp16net> in his bat cave
20:56:46 <SlickNik> Okay, let's talk about this in the channel tomorrow.
20:56:51 <kevinconway> he's stuck on that episode of the twilight zone where the plane keeps jumping around in time
20:56:55 <ashestakov> which time?
20:56:55 <kevinconway> he may be back yesterday
20:56:56 <kevinconway> or never
20:57:02 <datsun180b> <hub_cap> Ill be in a plane all day today. Ill be back online tomorrow back to normal!!
20:57:05 <datsun180b> via email
20:57:08 <amytron> he should be back tomorrow
20:57:36 <cp16net> ok sounds good
20:57:40 <SlickNik> Same time as today (1PST) should work, I think.
20:57:51 <cp16net> +1
20:58:02 <SlickNik> Okay, before we run out.
20:58:02 <vipul> ok
20:58:15 <SlickNik> Any other items for Open Discussion?
20:58:20 <vipul> don't forget Fantasy football draft at 3pm!
20:58:27 <vipul> :D
20:58:37 <SlickNik> Oh yeah :)
20:58:41 <amytron> haha nice vipul
20:58:47 <SlickNik> #endmeeting