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