20:00:10 #startmeeting trove 20:00:11 Meeting started Wed Oct 30 20:00:10 2013 UTC and is due to finish in 60 minutes. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:14 The meeting name has been set to 'trove' 20:00:25 o/ 20:00:27 o^/ 20:00:41 o/ 20:00:46 o/ 20:00:49 o/ o/ o/ o/ 20:00:57 kevinconway: has multiplied 20:01:05 #topic action items 20:01:10 #link http://eavesdrop.openstack.org/meetings/trove/2013/trove.2013-10-23-20.01.html 20:01:16 grapex to fix issue where instances in BUILDING_ERROR_DNS cannot be deleted. 20:01:37 hub_cap: Sorry, was tied up with a few other things. 20:01:51 k 20:01:55 #action grapex to fix issue where instances in BUILDING_ERROR_DNS cannot be deleted. 20:02:00 datsun180b to make conductor no longer optional 20:02:12 working on it 20:02:17 k 20:02:36 write up wiki article wrt testing + tempest + trove <--- fail, i didnt do any of it 20:02:37 review's up, but i've got one more patchset to push 20:02:42 yep, some good progress on it datsun180b! 20:02:55 but i suspect a good bit will be done at the summit, since SlickNik has a talk on it 20:03:10 o/ 20:03:10 ok time to move on 20:03:26 hub_cap: make sure your talk isn't just a bunch of sketches of the sea. 20:03:29 So... the only thing i have on the list is to talk about the summit 20:03:33 hub_cap: did you want to retask that item? 20:03:34 grapex: shit 20:03:41 or pictures of chicken and waffles 20:03:46 #link https://review.openstack.org/#/c/53972/ <= started on some of the pieces to get the ball rolling 20:03:51 #action write up wiki article wrt testing + tempest + trove (hub_cap SlickNik) 20:04:20 #topic talk about the summit 20:04:50 so one thing to note 20:04:55 o/ 20:05:15 summit |ˈsəmit| noun 20:05:16 1 the highest point of a hill or mountain. 20:05:17 2 a meeting between heads of government: 20:05:19 o/ 20:05:21 hub_cap : some draft review was shared with you around tempest cli test 20:05:23 the core team will be mostly radio silent for the next week (starting next week) 20:05:31 SnowDust: yes for some of it 20:05:40 im more concerened about the integration tests 20:05:41 err 20:05:46 the scenario tests 20:05:49 ok 20:05:52 and how to parallelise them 20:06:09 [0] 20:06:20 SnowDust: but u should totally add that to the summit session etherpad 20:06:24 SlickNik: can u link them 20:06:28 Yes 20:06:33 #link https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Trove 20:06:51 ^^All the summit etherpads 20:07:52 ok cool 20:08:00 so does anyone else have anything to really discuss? 20:08:20 or have questions / comments about the summit 20:08:20 datastore types? 20:08:25 So do we have names for the session leads? 20:08:40 names vipul? 20:08:53 everyone know which sessions they are leading? 20:09:06 and are there sessions without leads.. that we can assign people to 20:09:10 oh its the one u submitted :) 20:09:13 it says "submitted by" 20:09:27 ok.. i know which one i'm doing.. jsut making sure other do too :) 20:09:32 #link http://icehousedesignsummit.sched.org/overview/type/trove 20:09:35 * juice is happy to volunteer 20:10:01 will the etherpads be updated during the conference? that way folks like myself, who were sabotaged by calendar conflicts, can review them after the fact? 20:10:03 I'm leading the Guest Agents in Trove 20:10:16 amcrn: yes! 20:10:18 amcrn: yes they will be updated 20:10:22 stellar 20:10:40 hey whos going to the summit? 20:10:41 speaking of calendar conflicts. 20:10:56 id like ot get a feel for whos gonna be there 20:11:03 o/ 20:11:06 o/ 20:11:10 \o 20:11:13 * SlickNik will be there 20:11:13 o/ 20:11:37 i think isvidriov will be there too, right dmakogon? 20:11:40 denis_makogon: ^ ^ 20:12:17 I'm stowing away in grapex's luggage 20:12:27 hub_cap, yes 20:12:52 imsplitbit: if he packs like you, he will def have enough luggage 20:13:08 FYI to all going: this year there are _two_ calendars. 20:13:21 #link http://openstacksummitnovember2013.sched.org/ 20:13:22 ok so do we have more stuff to talk about wrt the summit? 20:13:31 #link http://icehousedesignsummit.sched.org/ 20:13:59 make sure you look at both when picking which sessions to go to. 20:14:18 also there is like a 10 minute walk between the 2 sched's 20:14:58 ok ill open this up to open discussion now 20:15:10 #topic open discussion 20:15:12 lets chat anything 20:15:14 I've got something 20:15:33 I'll take the mic after SlickNik 20:15:41 There's a time change coming up this weekend 20:15:46 lol yes there is 20:15:55 which means meeting time change right :) 20:16:03 yup. 20:16:09 silly UTC.... 20:16:10 for the DST'ers 20:16:12 :-P 20:16:16 for the DST'ers 20:16:19 why can't it always be DST 20:16:40 arizona, youre not invited to this conversation 20:16:41 because when everyone is DST then noone is DST 20:16:52 woah imsplitbit 20:17:02 it's so kids don't have to wait for the bus in the dark 20:17:04 imsplitbit: That's deep 20:17:19 momma says... 20:17:26 So is the plan then to keep to the same UTC time? 20:17:42 maybe we should try another 'redo' w the time 20:17:46 no we're moving them to 9am CST 20:17:53 right kevinconway 20:17:54 ? 20:17:55 since we actually have multiple continents who are contributing now 20:18:02 at least imsplitbit 20:18:38 so is that 12pm or 2pm for us 20:18:58 12 noon, I believe for PST 20:19:29 man I wish I could mozy into work after 10am... 20:19:33 * imsplitbit is jealous 20:19:39 actually let me double check 20:20:12 imsplitbit: you work from home :p 20:20:33 so lets keep the same time for now 20:20:44 yup it's noon 20:21:08 vipul: I wish 20:21:29 I'm fine with it keeping it the same for now. 20:21:56 Heads up that if you follow DST, the meeting time will be different for next week. 20:22:03 correct ^ ^ 20:22:10 is there a meeting next week? 20:22:21 i wonder what time that is in Hong Kong time 20:22:40 and obvi we skip next wks meeting 20:22:48 vipul: I vote we change the meeting time for one week while we're in HKG and then change it back afterwards. Would that be fair? 20:22:58 totally 20:22:58 4:00 am HKT :) 20:23:02 isn't putting all the core members in one building the plot of the newest star trek movie 20:23:03 #link https://www.google.com/search?q=what+time+is+it+in+hong+kong 20:23:24 ok so have we decided? 20:23:24 its 2 AM IST .. my time .. already ! 20:23:28 can I get the mic? 20:23:34 I'll be relatively quick 20:23:36 imsplitbit: talk 20:23:41 * SlickNik passes imsplitbit the mic 20:23:43 SPIT IT DAWG 20:23:44 #link https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API 20:24:19 we will be discussing this in the summit for sure 20:24:35 ok well then I'll hold off until it has been discussed 20:24:44 see that was fast. 20:25:02 I think this is pretty good 20:25:11 lol imsplitbit 20:25:14 don't forsee much change after the summit 20:25:18 also, just so everyone knows, https://review.openstack.org/#/c/54510/ 20:25:22 that should fix our build 20:25:26 right SlickNik? 20:25:54 yup 20:25:59 should/can I at least start adding the metadata attribute to the instances?? 20:26:10 * imsplitbit is chomping at the bit to get started 20:26:16 once we have a new pbr pushed to pypi 20:26:18 imsplitbit: if u want to risk throwing code away, start on anything u want ;) 20:26:20 SlickNik: Thanks! 20:26:29 dude I just threw away a bunch of code 20:26:32 I'm totally ok with that 20:26:40 at the risk of getting ahead of the game?? 20:26:46 I'll take that 20:27:05 SlickNik: your review is merged 20:27:34 guys, can we discuss datastore types review now? 20:27:46 PS: I want the mic after ashestakov. 20:28:05 * imsplitbit drops the mic and storms off stage 20:28:10 :) 20:28:15 * hub_cap wallops imsplitbit with a golden cup 20:28:17 hub_cap: waiting for mordred to push a new release to pypi. He said he'd get to it after he gets out of meetings. 20:28:22 * grapex hands the mic to ashestakov 20:28:33 aww grapex u forgot to pick up the mic 20:28:40 -10 exp 20:28:42 vipul: did you saw my answer for your comment? 20:28:52 hub_cap: harsh 20:29:00 -5 more for whining grapex 20:29:13 ashestakov: lets brign up the topic, explain it 20:29:15 where's the talking pillow 20:29:16 *bring 20:29:38 ok, this review https://review.openstack.org/#/c/47936/ 20:29:53 amcrn: /me needs to watch breaking bad 20:30:05 commants at https://review.openstack.org/#/c/47936/15/troveclient/v1/datastore_types.py L91 20:30:33 hub_cap: word 20:30:51 ashestakov: bring up the topic more than showing links 20:30:53 whats the issue 20:30:56 what do u want to talk about 20:31:04 ashestakov: You should probably requote your comments for everyone's convience. 20:31:10 vipul: whats the issue? 20:31:46 will better if vipul describe issue againe, maybe i missung something 20:32:10 k ashestakov 20:32:13 vipul: go 20:32:19 The issue seems to be that there are 2 different routes, one for types and a separate one for versions. 20:32:44 vipul has stepped away for a min. 20:32:59 I can go hunt around the office for him 20:33:08 When really, the versions are linked to the types and not independent of them. 20:33:12 lol esp we can give him a few min 20:33:21 back 20:33:33 phew, thought I was gonna have to check the restrooms 20:33:39 lol esp 20:33:44 so on the type and version deal, what was the reason for not simply using glance images? 20:33:45 ok my concern on that was.. why do we need that route? 20:34:02 by keeping that route in place we are treating versions as a higher level resource.. 20:34:21 if we agree that vesions are sub-resources of Types 20:34:35 then a valid route would be /datastore_types/{id}/versions/{v_id} 20:36:12 I agree with vipul on this — it hardly makes sense to request a list of all versions without type information. 20:36:41 SlickNik: vipul: +1 20:36:45 +1, even if you added a filtering mechanism, the version "belongs" to the type 20:36:54 SlickNik: you cant list all versions 20:37:03 SlickNik: only for certain type 20:37:33 ashestakov: that route doesn't alllow you to specify the type 20:37:45 you can list like: trove datastore-verion-list Mysql 20:37:59 vipul: that route only for one specified version 20:38:37 [13:36:44] +1, even if you added a filtering mechanism, the version "belongs" to the type 20:39:18 ashestakov: That's exactly it. I believe, the RESTful way to do this is not to specify it as a separate query param, but have it as part of the URI of the resource. 20:39:21 +1 versions are a sub resource 20:40:39 but if use this /datastore_types/{id}/versions/{v_id}, then need to specify type and version to get info about version 20:41:02 ashestakov: There are already cases where people must specify two ids 20:41:06 yes.. take for example 'instance' and 'users' 20:41:07 ashestakov: exactly 20:41:16 the database and user calls always force you to specify instance IDs 20:41:47 ok, that was my single point 20:41:53 ashestakov: And a GET on /datastore_types/{id}/versions would list all version of a particular datastore type. 20:42:01 yes 20:42:35 if decided, ill fix it 20:42:39 any other issues? 20:42:42 ok cool 20:42:54 nope looks good otherwise 20:43:04 will you approve it? 20:43:11 maybe 20:43:14 of course :P 20:43:44 if you fix it, they will come :) 20:43:45 i'll but this on the review, but why datastore_types vs. datastores 20:43:49 s/but/put 20:44:13 amcrn yea that's a good point 20:44:23 type seems redundant 20:45:29 lol @ amcrn where were u like a wk ago 20:45:41 dealing with internal infra stuff :P 20:45:55 sowwy 20:46:15 so ashestakov its called a datastore { "type".., "version"..} in the create, right? 20:46:36 hub_cap: yes 20:46:36 https://review.openstack.org/#/c/47936/15/troveclient/v1/instances.py 20:46:37 seems to be 20:46:59 see to me, if we are putting that "datastore" as the object, it should also be the collection, like /datastores, and should return type and avail versions in a single call 20:47:32 * hub_cap takes amcrns wrench and jams it further into the gears 20:48:43 do we really want to call it datastore? i like informationstation 20:48:56 kevinconway: Oh my God that's pefect! 20:48:59 kevinconway: lol 20:49:08 it killing me 20:49:18 informationstation: { dial1: blah, dial2: blah} 20:49:26 hub_cap: so to summarize: /datastores is a summary of all datastores, /datastores/:id is a summary of one datastore, /datastores/:id/versions is for a list of versions for one datastore, and /datastores/:id/versions/:id is the verbose information for a particular version of a datastore 20:49:44 yes 20:49:54 ill let yall duke it out after todays stuff 20:50:05 ok, just typing it out for posterity's sake 20:50:08 amcrn: +1 20:50:09 amcrn: I like that 20:50:11 sounds logical 20:50:13 id almost say that amcrn should do the work to fix it tho since hes so late to the party 20:50:23 * amcrn runs into the night 20:50:23 heh 20:50:25 poor ashestakov has been going rounds w/ it already 20:51:27 +/u/bitcointip @ashestakov $1 20:51:32 hub_cap: I 20:51:36 'd like to discuss something 20:51:44 grapex: K 20:51:59 i think just datastores is confusing 20:52:00 ashestakov: amcrn duke it out after the meeting in #openstack-trove 20:52:06 https://review.openstack.org/#/c/54565/ <-- This is a tiny fix for backups and the testing of backups. 20:52:41 grapex: I'll take a look this afternoon. 20:52:45 SlickNik: Thanks 20:53:11 I have a slightly larger review, which could use some eyes 20:53:13 https://review.openstack.org/#/c/53381/ 20:53:45 Basically removing a bunch of tests that are Rackspace specific and general cleanup 20:53:56 nice 20:55:03 * SlickNik will spend some time reviewing tests this afternoon/evening. 20:55:14 * SlickNik adds robertmyers review to list 20:55:30 ok so we good to go? 20:55:36 did we decide on if we're having a meeting next week? 20:55:39 SlickNik: thanks! 20:55:42 there is a list of reviews on the site too :-P 20:55:44 kevinconway: no meeting 20:55:48 by decree of me 20:56:04 * hub_cap puts any cp16net reviews to the bottom of said list 20:56:05 I know cp16net, I'm gonna take a look at everything that looks ready for review. 20:56:06 decree |diˈkrē| noun 20:56:07 an official order issued by a legal authority. 20:56:08 verb 20:56:09 order (something) by decree: 20:56:18 i can make them show up at the top 20:56:20 LGTM 20:56:33 well the gate needs to be rerun on everything... 20:56:43 #endmeeting