18:00:23 #startmeeting trove 18:00:24 Meeting started Wed Jan 22 18:00:23 2014 UTC and is due to finish in 60 minutes. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:00:27 hi all 18:00:28 The meeting name has been set to 'trove' 18:00:32 o/ 18:00:41 here 18:00:46 hub_cap: Ireland has never seen 44C ;) 18:00:48 o/ 18:00:50 * kiall gets out of the way 18:00:56 o/ 18:01:06 o/ 18:01:12 o/ 18:01:15 o/ 18:01:38 o/ 18:01:40 ok so lets get this party started 18:01:41 o/ 18:01:49 o/ 18:01:52 is the party over here 18:01:54 #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting 18:01:56 o/ 18:01:58 aye datsun180b 18:02:09 o/ 18:02:10 that is a serious query, my party locator is malfunctioning 18:02:21 LOL 18:02:28 ok so this is another small meeting heh 18:02:32 no datsun180b the party is over there 18:02:57 so, lets get on w/ the first item (im switchign the agenda) 18:03:06 #topic kill tha xmls 18:03:24 +1 18:03:30 * grapex screams in terror! 18:03:32 so, the TC has said that its a-ok to remove from future apis 18:03:42 lol@grapex 18:03:45 rip that sucka out 18:03:48 and told trove that we can/should remove before our first integrated release 18:03:52 o/ 18:04:10 grapex: i thought you'd be relieved 18:04:39 hub_cap: How long does that give us again? 18:04:47 ok so we are going to have to let this sit for about a month i think 18:04:50 itll be beore feature freezer 18:04:52 lol 18:04:53 freeze 18:05:19 #link https://wiki.openstack.org/wiki/Icehouse_Release_Schedule 18:05:27 for all your release date needs. 18:05:29 I'm down for removing it- but we think maybe one or even two people at Rax use it now, so its a bit tricky. 18:05:43 but id like to give any company who is removing this time to call peoples :) 18:05:51 hub_cap: Cool 18:06:57 so we have no problems w/ this then? 18:07:12 burn xml to the ground 18:07:14 salt the earth 18:07:15 otehr than making sure we give companies time to tell that guy 2003 called and wants their xml back? 18:07:17 leave a sign 18:07:30 datsun180b: nice touch, leaving a sign 18:07:32 datsun180b: are you saying xml is the salt of the earth? 18:07:38 oh geez 18:07:42 kevinconway: startrd, lets move 18:07:49 lol 18:08:08 #topic conductor message sync strategies 18:08:15 yes hello 18:08:43 so tim noticed before our holiday conductor introduced a potential problem 18:09:13 that is, syncing statuses of instances and backups is no longer a database update, but a message-in-a-bottle rpc cast, so we could find ourselves with an instance in one state 18:09:28 but conductor might be bogged down and so the db would be out of date 18:10:08 and if messages can get to conductor out of order, things can get even worse, so what we need to do is make sure that conductor makes its updates in the right order, especially in the face of multiple conductor workers 18:10:45 i've got a pull request that's halfway there, a sent_at field compared to the updated field of the tables, but i can do one better because the guest and host's timekeeping could skew and cause problems still 18:11:33 hub_cap suggested that i ask nova's conductor peeps for their sync strategy, but otherwise i'd add a table that only conductor uses, to pair (instance, message) -> timestamp from guest 18:11:37 is this thing on? 18:11:43 Yup, good call on this grapex/datsun180b. 18:11:44 we are listening 18:11:46 yup, listening 18:11:55 basically yer saying good stuff 18:11:59 okay recap: 1. i add a new table only conductor uses 18:12:00 so only cweid will argue w u 18:12:00 yes, listening 18:12:16 2. chances are this is old territory long since covered by nova and they have a better idea 18:12:46 afaik nova is async when it sends host updates 18:13:28 i don't think making a guest agent wait until conductor confirms status updates is the right way to go, though 18:13:43 yes vipul but how does it handle the potential race between a customer call and a guest update :) 18:14:05 but datsun180b will hit us up w/ a review and/or updates from the nova crew 18:14:18 hub_cap: Yea, that's an issue, but we may want to consider handling it at the guest.. 18:14:20 porque no los dos? 18:14:28 the guest doesn't look at its own state 18:14:44 vipul: yea i want to make sure we solve that in some way, and datsun180b has a handle on it 18:14:50 i think the best we can do is ask the guest what time it thinks it is every time it sends a message 18:15:17 datsun180b: +1 18:15:22 and for conductor to keep a ledger to at least keep each instance's story straight, at least self-consistent 18:15:39 datsun180b: cool that'll solve the out of order issue 18:16:44 okay, so #action datsun go add a conductor sent_at table and #action datsun go talk to nova about conductor ? 18:17:14 sounds good datsun180b 18:17:33 datsun180b: u gotta start w/ #action 18:17:35 #action datsun180b add sent_at table for conductor to sync messages from guests 18:17:35 sounds good to me. 18:17:52 moving on 18:17:52 #action datsun180b talk to nova team about their conductor sync strategy 18:18:01 #topic tempest work 18:18:02 thank you all 18:18:46 The couple of devstack-gate reviews that I had are taking a while to get merged. 18:19:18 I haven't been bothering the CI team too much about it, since they're crazy busy dealing with zuul/gate issues at the moment. 18:19:49 so SlickNik, do you anticipate working on the image caching stuff next? 18:19:52 Hopefully that'll change once i2 gets cut. 18:19:54 so by looking at that etherpad, the next step for tempest trove is to write some API acceptance tests. is that correct? 18:20:37 Yes, kevinconway. That is correct. 18:20:52 Right now, to test it out, you can pull the devstack-gate changes from gerrit. 18:21:08 will we be able to run the acceptance tests against different data stores as a part of tempest? 18:21:44 The guest related tests can't go in until the image stuff is figured out.. is that correct? 18:21:47 Was any Trove specific code for Tempest written during the time I dropped off the Earth? 18:21:56 kevinconway: Eventually. We're starting of with just mysql, but the end goal is to port all of what is in trove-integration to Tempest. 18:22:20 We could use Fake Mode while we wrote more tests. 18:22:33 That way we could write tests even if the image stuff isn't set up yet. 18:22:45 hub_cap: Yes, I'm working on the image caching work in parallel. 18:22:47 SlickNik: id prefer to see the initial goal to be make devstac/tempest do what trove-integration does now 18:22:51 cool SlickNik 18:23:29 If we use Fake Mode, there's no reason we couldn't try porting some of the more complex test cases right away. 18:24:06 grapex: I started writing a couple of 'service' pieces for trove for the flavors API. I'll push a patch set up within the next couple of days. 18:24:14 does Tempest have a fake mode? or is it focused purely on end to end 18:24:34 vipul: If it can hit various environments that shouldn't matter. 18:24:40 We can start a fake mode daemon and hit that 18:24:42 vipul: Looking at other components, it seems like it's entirely end-to-end. 18:24:56 where can i read more about tempest? i feel like there's something i don't understand 18:25:41 kevinconway: wiki.o.o/Tempest would be my guess 18:25:46 grapex: In order to do that we'd have to be able to enable a fake mode demon in devstack, I think. Might be something worth looking into. 18:26:01 kevinconway: hang on a sec. 18:26:17 #link http://docs.openstack.org/developer/tempest/ 18:26:19 lets start w/ real mode tests :) 18:26:20 SlickNik: I think it would be worth it. In fact, it wouldn't be a bad idea to test via Fake Mode in CI- there's plenty of stuff the daemonized version can find that the version we run in Tox can't quite see. 18:26:37 then lets try to find a way to capitalize on the "fakes" that sdague talked about in our summit talk 18:26:38 but to clarify, our plan is to rewrite all of our tests using tempest? 18:26:50 hub_cap: I think we should do them in parallel. That way we can know things aren't inflexible. 18:27:07 heh, im not sure SlickNik has the bandwidth for that ;) 18:27:11 hub_cap: I think that was an idea and not existing work. 18:27:12 hub_cap / grapex: Yeah my approach was to start with the real mode, and add the fake mode later once we have built some social capital with the tempest folks. 18:28:19 There might be some initial push back, since this (fake mode) is different from what a other OS teams are doing. 18:28:19 SlickNik: Ok, you have to start somewhere. However in my experience fake mode is working now with the int tests that run with Tox on each check in, and it'll be easier to write the tests that way since the feedback will be so quick. 18:29:28 SlickNik: Ok- maybe just consider it as a tool you can use while writing tests. 18:29:41 grapex: I hear you. Let's look at that once we have some set of real mode tests (even if it's some basic ones). 18:29:42 grapex: i suspect that might be much work w/ tempest internals to get that all working 18:30:50 grapex: I feel it's a worthwhile exercise to do things the tempest way (initially at least) so that we can learn some of the ropes as well, since it does have some new ways of dealing with things. 18:31:01 hub_cap: I hope not- my understanding is it can run against any environment. 18:31:50 But you guys are probably right in that it would be easier to start with real. 18:32:04 Anyhow, some of you wanted to start looking into some of these tests as well (denis, and some other globallogic and mirantis folks) 18:32:50 so we done w/ this topic? 18:32:51 So I've just put up a quick etherpad to indicate what pieces each of us might be working on. 18:32:57 Ok, let's start with real. I just want us to try to stay open minded. I'd hate it if the "canonical" Trove tests became something I couldn't run or play around with unless I had a fleet of servers at my finger tips. 18:33:09 So feel free to update if you're starting to look at a piece. 18:33:16 #link https://etherpad.openstack.org/p/trove-tempest-items 18:33:16 grapex: right now itll be no more than the current tests 18:34:05 Also feel free to ping me in openstack-trove if you have any questions regarding any of this. 18:34:31 ok so movin on 18:34:31 And with that I'm good to move on. 18:34:33 Ok. 18:34:36 Thanks SlickNik! 18:34:53 anytime, np. 18:35:28 #topic datastore mgmt api 18:35:31 ashestakov: tag 18:36:24 i want propose mgmt API spec for datastores 18:36:53 to move create/update datastores/versions from trove-manage to API 18:37:03 this is my gist https://gist.github.com/andreyshestakov/8557935 18:37:07 pls look 18:38:33 I guess I don't have enough context to know why you would want to do that 18:38:46 ok anything else to that ashestakov ? 18:38:57 ashestakov: should those urls be /mgmt/blah 18:39:05 ashestakov: so this api would allow manipulating the datastore on a guest instance without tearing down the instance? 18:39:07 +1 robertmyers 18:39:32 esp: more like the datastores in the db, I would think. 18:39:35 esp: no guest instance, just create/update 18:39:46 to updated the datastore instances in the models. 18:40:04 +1 on /mgmt (robertmyers' suggestion) 18:40:26 i saw same impl for configuration-groups 18:40:29 k, I think I get it 18:40:30 without /mgmt 18:40:51 configurations is for the user 18:41:00 not an admin 18:41:13 only admins will create datastores 18:41:25 ok, just /mgmt/datastores/... ? 18:41:29 isn't /mgmt stuff only supposed to be exposed via trove-manage or did I misunderstand that? 18:41:32 yes 18:41:52 jimbobhickville1: naw 18:41:54 jimbobhickville1: well, no 18:41:55 u can expose via the cli too 18:41:58 i think mgmt stuff should be in trove cli 18:42:01 yes 18:42:09 "initial setup" stuff should be in trove-manage 18:42:10 i think amcrn was working on that last time we met 18:42:19 ok, cool, that's timely advice since I was about to do the wrong thing 18:42:26 and "tweaking" stuff (like adding a datstore) shoudl be in the mgmt api 18:44:05 anything else to add, ashestakov? 18:44:08 any comments except /mgmt ? 18:44:52 should troveclient has commands for mgmt api? 18:45:07 ashestakov: yes, it use to 18:45:30 i didnt see any mgmt commands in troveclient 18:45:38 only in trove-mgmt-cli while ago 18:45:39 ashestakov: i removed them cuz our mgmt api is mostly busted 18:45:57 and had few if any tests added 18:46:03 thanks for the vote of confidence, technical leadership! 18:46:09 hahahaahah 18:46:14 ashestakov: maybe lines 36-37 should be: 18:46:14 Create version 18:46:14 POST /datastores/{id}/versions 18:47:02 SlickNik: why /versions? 18:47:39 SlickNik: i agree 18:48:03 really a nitpick, but it seems like you'd want your URI to indicate that it was a create operation on a version. 18:48:50 a POST to /datastores/{id} could be for any operation really, and you'd have to peek into the body to see that it was a version create. 18:48:56 /datastores/id already means versions, like in GET 18:49:29 GET /datastores/ should give you the data store 18:49:39 why would it give you versions instead? 18:50:01 oops 18:50:13 ok, i agree vit /versions 18:51:20 any other comments? i have one more point to discuss 18:51:38 Okay, thanks. 18:52:47 I think we're good. 18:52:53 cool 18:53:02 Let's speed things up a bit to leave some time for open discussion. 18:53:11 So go ashestakov. 18:53:12 ++ 18:53:21 moving on 18:53:41 #topic Datastore versions migrations/upgrades 18:53:45 lets look here https://gist.github.com/andreyshestakov/8559309 18:53:48 oh no 18:53:55 big topic for 7 minutes 18:53:56 this is API for migrations 18:54:29 this is base on approach suggested by amcrn https://gist.github.com/amcrn/dfd493200fcdfdb61a23 18:54:30 how are we separating upgrades from migrations? 18:55:09 we should probably tackle upgrades first? 18:55:31 are we defining upgrades to be in place and migrations require a new instance? 18:55:35 vipul: agreed 18:55:40 Note: Chose the term migration over upgrade because the latter indirectly suggests that downgrades (ex: from 5.6 to 5.5) and/or datastore transitions (ex: from MySQL to Postgres) are not possible. 18:55:46 that's what my understanding was kevinconway 18:56:15 I want to migrate from mysql to redis, go! 18:56:21 ashestakov: I don't know if migration is the right term. It implies it's not in place. 18:56:35 jimbobhickville1: i think that would be possible with this api if you define a migration manager 18:57:11 are we going to then have to have some way to define possible migration paths so a customer can know what's a valid path or not? 18:57:25 although, now that I think of it, it doesn't necessarily have to be (it's just used that way in OS, so it's loaded). 18:58:10 jimbobhickville1: yes, with ashestakov's api you would define valid migration paths 18:58:25 cool 18:58:38 #link https://gist.github.com/andreyshestakov/8559309 18:58:41 that's the gist he posted 18:58:54 I should probably read that then 18:59:06 ashestakov: yeah i think you need to ML this topic 18:59:11 +1 18:59:13 i'm sure you'll get lots of advice 18:59:21 I think we might need more time to read/digest this. 18:59:25 So +1 for ML 18:59:35 this is big 18:59:40 lets hope migrations isn't the next users 18:59:41 ok, ill answer in ML 19:00:05 ok so no open discussion 19:00:09 #endmeeting