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