18:02:10 <hub_cap> #startmeeting trove
18:02:11 <openstack> Meeting started Wed Mar  5 18:02:10 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:02:11 <juice> o/
18:02:13 <abramley> o/
18:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:13 <grapex> o/
18:02:15 <SlickNik> o/
18:02:16 <openstack> The meeting name has been set to 'trove'
18:02:16 <amcrn> o/
18:02:16 <robertmyers> o/
18:02:17 <cp16net> what up
18:02:18 <hub_cap> heyo troops
18:02:23 <denis_makogon> o/
18:02:25 <kanzaros> o/
18:02:27 <glucas> o/
18:02:34 <esp> o/
18:02:36 <pdmars> o/
18:02:41 <doug_shelley66> o/
18:02:51 <hub_cap> okey doke
18:02:55 <kevinconway> o\
18:03:01 <amytron> o/
18:03:01 <esmute> o/
18:03:04 <hub_cap> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:03:09 <imsplitbit> o/
18:03:19 <hub_cap> ahh so many head+hand combos
18:03:26 <hub_cap> #topic guest agent upgrades
18:03:28 <Barker> o/
18:03:29 <hub_cap> so whoes up for this?
18:03:40 <juice> esp take it away
18:03:44 <SlickNik> esp
18:03:44 <imsplitbit> LETS ROCK!
18:03:48 <esp> k
18:03:49 <imsplitbit> :)
18:03:49 <hub_cap> hollah
18:03:53 <amcrn> \m/
18:04:02 <imsplitbit> sorry Aliens reference
18:04:12 <esp> so I put together a wiki page to describe the work for implementing guest agent upgrades
18:04:22 <hub_cap> i think amcrns ascii art was too
18:04:23 <esp> link: https://wiki.openstack.org/w/index.php?title=Trove-Guest-Agent-Upgrades
18:04:35 <esp> #link https://wiki.openstack.org/w/index.php?title=Trove-Guest-Agent-Upgrades
18:05:05 <hub_cap> so what shall we discuss with this, besides the fact that this is an epic awesome wiki page
18:05:14 <juice> esp: nice and thorough job on this
18:05:15 <imsplitbit> +1
18:05:22 <kevinconway> esp: did you use visio for this?
18:05:24 <esp> hub_cap: I made cartoons for everyone to enjoy
18:05:24 <cp16net> yeah thats what i was thinking.
18:05:33 <SlickNik> good job on the wiki page, esp
18:05:33 <hub_cap> esp: :)
18:05:33 <esp> kevinbenton: omni graffle
18:05:45 <cp16net> ah i was hoping for a flip book
18:05:50 <cp16net> :-P
18:05:52 <hub_cap> its going to print cp16net
18:06:00 <hub_cap> give it 6wks for first run
18:06:07 <hub_cap> esp and the interwebs
18:06:14 <esp> and mysql work bench for the DB table
18:06:19 <juice> I am guessing not many people had time to review this
18:06:20 <SlickNik> Gonna make some time to review it today, and will comment on the wiki page.
18:06:29 <amcrn> i put some comments @ the bottom of the wiki already
18:06:31 <hub_cap> yea im skimming it now, but it looks similar to what weve discussed before
18:06:34 <amcrn> and esp kindly responded
18:06:34 <hub_cap> and at the mid cycle
18:06:38 <denis_makogon> juice, +1
18:06:40 <esp> juice: no, it was kinda late getting into the agenda
18:06:43 <juice> should we have a period for comments - say a week and then close it and call it approved by next week
18:06:59 <grapex> I guess I have some confusion over process
18:07:01 <amytron> juice +1
18:07:08 <amcrn> yeah, i'd just ask that those with specific packaging needs add information to the wiki so it's considered appropriately
18:07:15 <juice> unless there are some questions right off the top that esp can answer now...
18:07:16 <denis_makogon> juice, +1
18:07:19 <esp> yep, take some time to tear it apart
18:07:29 <grapex> maybe we need to finish up the talk we started at the summit, but wasn't one idea that the blueprint would link to the wiki, and we'd approve the blueprint first?
18:07:42 <esp> grapex: yep
18:07:51 <esp> I did link it though.. let me dig up the bp
18:07:57 <hub_cap> yea grapex, but im just getting back to the swing of things
18:08:03 <vipul> i think hub_cap should go over the new process so everyone knows
18:08:05 <kevinconway> esp: create a bug describing the missing link to the wiki
18:08:05 <grapex> hub_cap: Me too :D
18:08:07 <cweid> o/
18:08:12 <hub_cap> this would be a perfect candidate for part1 and part2 of what we talked about at the mid cycle
18:08:20 <esp> kevinconway: lol
18:08:23 <hub_cap> part1=bp approve w vision, p2=wiki of awesomeness
18:08:30 <cp16net> true
18:08:37 <juice> so we are a bit backwards this time
18:08:41 <grapex> hub_cap: so when do we approve what's in the wiki?
18:08:51 <hub_cap> grapex: id say after we get to the bp vision
18:08:56 <hub_cap> but honestly
18:09:01 <hub_cap> this one is obvi, we talked about it
18:09:04 <hub_cap> so to me the bp is approved
18:09:14 <hub_cap> since we had a big duscussion on the mid cycle etc...
18:09:19 <hub_cap> *Discussion
18:09:19 <grapex> Probably it is, I'd just like a chance to read it first, similar to a pull request.
18:09:24 <hub_cap> def dude
18:09:25 <cp16net> and then beginning kinda describes what the bp would be
18:09:25 <esp> grapex: https://blueprints.launchpad.net/trove/+spec/upgrade-guestagent
18:09:31 <esp> #link https://blueprints.launchpad.net/trove/+spec/upgrade-guestagent
18:09:31 <hub_cap> lets defer maybe till next wk
18:09:32 <grapex> Thanks esp!
18:09:35 <cp16net> between the intro and goals
18:09:35 <hub_cap> and use this as our poster child
18:09:39 <esp> grapex: np
18:09:46 <hub_cap> and give esp a chance to dust off the bp
18:09:48 <hub_cap> if needed
18:09:48 <cp16net> yeah that sounds good
18:09:53 <SlickNik> I'm good with approving the bp. There might be some design details that need to be figured out.
18:09:55 <cp16net> i've not looked over this yet..
18:09:59 <juice> is the bp vision-y enough
18:10:11 <grapex> So- the whiteboard section- seems like there could be some overlap between that and the wiki
18:10:25 <esp> sounds good to me.  thx for looking at it.
18:10:28 <kevinconway> should we add inspirational quotes to BP to make them more visiony?
18:10:42 <imsplitbit> :)
18:10:47 <hub_cap> yea i hate whiteboard grapex
18:10:52 <grapex> kevinconway: I thought all Wiki articles were to begin with "In the course of human events.."
18:11:13 <grapex> So let's remove the whiteboard part for now
18:11:17 <grapex> Seems redundant
18:11:19 <amcrn> +1
18:11:35 <hub_cap> so even tho this bp is somewhat approved in our minds, lets use it as our next wk (mon/tue) discussions w core
18:11:41 <kevinbenton> esp: ?
18:11:48 <esp> k, I will transpose the whiteboard stuff to the wiki
18:11:59 <juice> wrong person kevinbenton - sorry
18:12:15 <SlickNik> I'm adding it as an agenda item to next weeks meeting.
18:12:23 <hub_cap> sweet thx SlickNik
18:12:30 <hub_cap> we can use that on monday to discuss bps
18:12:33 <juice> for everyone else can we get your comments on this before next weeks meeting?
18:12:43 <hub_cap> we still need to discuss the finer points of log delivery too
18:12:43 <grapex> hub_cap: I have a confession- I haven't read this bp yet!
18:12:45 * grapex blushes
18:12:51 <juice> since the wiki is already there, no need to hold up the review of that, right?
18:12:59 * hub_cap giggles w grapex
18:13:12 <hub_cap> juice: sure, anyone can review now
18:13:25 <hub_cap> we will discuss mon or tue a set of the bps
18:13:28 <hub_cap> i believe we said monday
18:13:30 <hub_cap> iirc
18:13:39 <hub_cap> w might need to consult the etherpad
18:13:43 <grapex> So about the whiteboard
18:13:52 * amytron rolls her eyes
18:13:55 <esp> grapex: it's probably best.. I don't know if the bp and wiki are exactly 1 for 1
18:14:00 <grapex> Maybe it would work for just notes such as "implemented by the following gerrit item"
18:14:09 <grapex> instead of sort of defining what the wiki is already saying
18:14:46 <hub_cap> lol
18:15:12 <hub_cap> grapex: it can work but its VERY Strict in the actual syntax
18:15:13 <juice> if we want to discuss the merits of the blueprint this isn't a great candidate because you have to consider what you would like in the blueprint in absence of the wiki
18:15:24 <esp> grapex: I'll take a look at it today and see if I can clean up the whiteboard (delete stuff)
18:15:25 <SlickNik> grapex: That's what I use it for. eg: https://blueprints.launchpad.net/trove/+spec/trove-tempest
18:15:40 <juice> and how much information you as a core team would need in order to send someone off to do the research that esp did for this in order to generate a wiki doc
18:15:43 <grapex> SlickNik: ++
18:15:48 <hub_cap> just clikc that little help link if anyone has issues
18:15:56 <hub_cap> its annoying, but nice to see for muliple patches
18:16:14 <hub_cap> oh sorry grapex
18:16:16 <hub_cap> im thinking work items
18:16:24 <hub_cap> whiteboard is fine for this ++
18:16:48 <hub_cap> ok so lets give esp till mon to clean it up
18:16:56 <hub_cap> and we can review it mon as a group in the channel
18:17:16 <esp> thx everyone!
18:17:47 <hub_cap> so moving on
18:17:57 <hub_cap> #topic replication/clustering update
18:18:32 <hub_cap> so whos on first?
18:18:33 <denis_makogon> imsplitbit, i guess its your turn ?
18:18:38 <imsplitbit> hmm
18:18:42 <SlickNik> So just a quick update on this.
18:18:43 <imsplitbit> ok so what is clear to me
18:18:48 <imsplitbit> oh good
18:19:07 * imsplitbit waits for SlickNik to tell us
18:19:14 <denis_makogon> whats the status with meta-data  ?
18:19:31 <SlickNik> We had a teamspeak meeting about this yesterday.
18:20:03 <denis_makogon> SlickNik, cool, have you got the  meeting minutes ?
18:20:32 <doug_shelley66> i think 3 things were decided, right?
18:20:32 <SlickNik> Main outcomes were 1. Imsplitbit to push up the API code with few changes to schema based on comments.
18:21:09 <SlickNik> 2. Folks from tesora to come up with bp for replication v1
18:21:52 <SlickNik> 3. And the tesora folks are eager to get started on implementation based on the bp.
18:21:59 <hub_cap> horray!
18:22:06 <denis_makogon> please elaborate p.2 and p.3
18:22:08 <kevinconway> wait, is that last one a decision?
18:22:30 <doug_shelley66> also wasn't amcrn doing something moving forward on clustering?
18:22:37 <hub_cap> lol kevinconway
18:22:40 <SlickNik> well that tesora was gonna work on it was the decision.
18:22:47 * hub_cap glares at amcrn
18:22:53 <denis_makogon> as discussed at the last meeting we're going to have common meeting in hangout for everyone who interested in taking part in replication implementation
18:22:54 <vipul> amcrn: are you sending the updated api ?
18:23:02 <amcrn> correct, there's still work being done in fleshing out the rest of the clustering api (building on the replication contract that everyone is preliminarily agreed upon)
18:23:11 <amcrn> vipul: i haven't updated it based on your comments last night yet
18:23:17 <amcrn> i can send it out, tomorrow?
18:23:33 <vipul> yea sure.. i think imsplitbit and doug_shelley66 shoudl be itnerested in it
18:23:43 <hub_cap> heh lets shoot for fri amcrn
18:23:53 <hub_cap> we have to prepare for a talk tomorrow
18:23:55 <amcrn> fair enough, today is an all-day deal
18:23:56 <hub_cap> :P
18:24:00 <hub_cap> as is tomorrow
18:24:02 <hub_cap> :D
18:24:04 <amcrn> word
18:24:06 <vipul> denis_makogon: i think this feature is concise enough that it makes sense to have a dedicated owner
18:24:08 <SnowDust> SlickNik, testing using tempest strategy ? can we talk ?
18:24:19 <vipul> denis_makogon: you can work wth doug_shelley66 to see if there are tasks he'd like you to take on
18:24:31 <hub_cap> SnowDust: u should put things on the meeting agenda
18:24:42 <hub_cap> lets finish this first before we get started w/ somethign else
18:25:13 <SnowDust> hub_cap : thought it was the last .. but will wait for the last in the agenda
18:25:37 <hub_cap> ok good to go? (looks like it might be SnowDust ;) )
18:25:59 <hub_cap> imsplitbit: doug_shelley66 SlickNik good?
18:26:08 <imsplitbit> so where I'm unclear
18:26:08 <doug_shelley66> i'm good
18:26:12 <SlickNik> good here.
18:26:15 <hub_cap> go on imsplitbit :)
18:26:17 <imsplitbit> is we never decided on if instances had nodes
18:26:18 <imsplitbit> or not
18:26:19 <SlickNik> Thanks guys!
18:26:34 <vipul> i think that vote will need to happen enxt week
18:26:38 <hub_cap> imsplitbit: lets discuss that next wk
18:26:38 <imsplitbit> ok
18:26:39 <vipul> that doesn't impact replication though..
18:26:42 <amcrn> correct
18:26:45 <hub_cap> during the monday bp talk
18:26:48 <hub_cap> if the bp is ready
18:27:07 <imsplitbit> do I own that?
18:27:08 <imsplitbit> :)
18:27:18 <hub_cap> i mean, whoever owns the bp owns it
18:27:23 <kevinconway> ok so you folks are going to decide that on monday. so i don't need to study for next weeks trove meeting right?
18:27:28 <hub_cap> i think tesora said they were going to take it over?
18:27:38 <hub_cap> kevinconway: no, plz study
18:27:43 <hub_cap> all wknd
18:27:43 <doug_shelley66> yes the BP for replicatoin v1
18:28:07 <hub_cap> we should re-approve all the inflight and new features
18:28:16 <doug_shelley66> ok
18:28:19 <hub_cap> amcrn: SlickNik vipul grapex how do yall feel about that?
18:28:29 <hub_cap> the inflight juno's and the not impld one
18:28:31 <hub_cap> ones
18:28:36 <hub_cap> not all on monday
18:28:39 <grapex> hub_cap: I like it
18:28:39 <amcrn> agreed
18:28:40 <hub_cap> but the ones that are worked on
18:28:42 <vipul> i like that
18:28:44 <hub_cap> or are about to be
18:28:44 <SlickNik> hub_cap: +1
18:28:49 <hub_cap> ok ill clean it up and unapprove
18:28:52 <hub_cap> sorry in advance
18:28:56 <hub_cap> but ther eis no reason to fret
18:29:04 <hub_cap> unless u have no wiki pages!!!!!
18:29:05 <hub_cap> ;)
18:29:23 <hub_cap> but we wont be terribly strict, lets work thru it liek a happy family :)
18:29:30 <hub_cap> ok so now we move on!
18:29:32 <hub_cap> good?
18:30:17 <kevinconway> but what about...
18:30:38 <hub_cap> dont say it
18:30:44 <hub_cap> #topic tempest update
18:30:45 <SnowDust> :)
18:30:48 <hub_cap> SlickNik: go go go
18:31:15 <SlickNik> So the initial tempest tests for trove are approved.
18:31:20 <hub_cap> hooray
18:31:28 <grapex> yaaaaaay
18:31:29 <SlickNik> It's currently in the merge gate.
18:31:44 <SlickNik> #link https://review.openstack.org/#/c/69501/
18:32:01 <amytron> that is awesome!
18:32:03 <SlickNik> Next steps are to make the job non-experimental
18:32:23 <denis_makogon> SlickNik, what's the status of dib elements  ?
18:32:25 <SlickNik> So other projects (devstack!) can gate on it.
18:32:29 <cp16net> how long is it taking SlickNik ?
18:32:36 <hub_cap> SlickNik: thatll be SO cool!
18:32:42 <SlickNik> currently it's about an hour.
18:32:45 <hub_cap> proly wont gate until juno
18:32:46 <cp16net> ouch
18:33:04 <cp16net> but its a good frist step
18:33:10 <cp16net> awesome
18:33:19 <SlickNik> cp16net: I need to identify the tests that we actually care about to reduce the execution time.
18:33:26 <SnowDust> test-refactoring for tempest .. ideas ?
18:33:29 <SlickNik> denis_makogon: That's the next step
18:33:51 <hub_cap> hey im putting to open discussion
18:33:56 <hub_cap> ill bb in a min
18:34:00 <hub_cap> #topic open discussion
18:34:05 <hub_cap> sorry, conflicting meetings :/ :/
18:34:14 <SlickNik> SnowDust: We don't have any code to refactor yet.
18:34:37 <SlickNik> We need to get _a_ datastore's tests into tempest before we can get multiple datastores.
18:34:37 <SnowDust> SlickNik ur bp says so .. https://blueprints.launchpad.net/trove/+spec/trove-tempest
18:34:50 <grapex> SlickNik: So, about rewriting the clients again. It seems like the desire of the Tempest authors to rewrite the clients stemmed from a need to test both JSON and XML
18:35:17 <SnowDust> SlickNik, got ur point
18:35:35 <grapex> however, since our existing client can do that, and since XML is going away anyway, can we start using the client for the tempest tests? I'd hate to have to duplicate the effort of writing a Python rich client binding for the Tempest tests.
18:36:09 <SlickNik> grapex: That's something that I'm going to start looking into.
18:36:15 <robertmyers> I think the tempest project doesn't want to be dependant on all the clients
18:36:24 <SlickNik> I'd hate to re-implement _all_ of our client functionality.
18:36:40 <robertmyers> cause it is a dependancy nightmare
18:36:42 <cp16net> sounds like copy pasta
18:36:43 <grapex> robertmyers: That would be ironic since if you run Tempest you're essentially dependent on literally all of integrated OpenStack. :p
18:37:01 <SnowDust> cp16net:   :)
18:37:20 <robertmyers> grapex: depends on how you install tempest
18:37:25 <SlickNik> robertmyers / grapex: There seem to be different schools of thought on that. And it's a conversation I can't wait to start with some of the Tempest folks :P
18:37:29 <grapex> I get that technically it's challenging to include a dependency on the client, but since our client doesn't depend on anything else it shouldn't be that bad.
18:37:46 <grapex> SlickNik: Be sure to CC me when you do
18:37:53 <SlickNik> grapex: definitely will
18:38:03 <cp16net> SlickNik: maybe they are afraid of a slippery slope
18:38:13 <grapex> I have seen some quasi- philosophical reasons for re-creating the clients, such as not being able to trust the original clients
18:38:42 <grapex> which I think points to a completely different problem. But yeah, let's talk about it at least before we have to start re-writing the entirety of the Trove python client.
18:39:16 <SlickNik> agreed
18:39:51 <SlickNik> That's pretty much all I had.
18:40:04 <demorris> I have a topic, can we chat real quick about adding datastore type details into backup metadata for backups stored in swift?
18:40:04 <SlickNik> as an update.
18:40:35 <demorris> This is not done today, but I am not sure if there is a BP for it
18:41:11 <grapex> demorris: I thought we agreed to add to the docs "users are expected to write down the specific datastore type they used to create each backup so they can remember it later."
18:41:15 <robertmyers> grapex: https://github.com/openstack/tempest/blob/master/tempest/clients.py#L434
18:41:18 <demorris> its fairly straightforward, store the type/version details in the backup metadata, so you can tell what datastore type and version a particular backup belongs to
18:41:21 <robertmyers> so i'm wrong
18:41:30 <imsplitbit> grapex: post-it notes yah?
18:41:43 <robertmyers> grapex: they do what you want
18:41:49 <demorris> grapex: yes, they should write it in sharpie on their hand
18:41:58 <grapex> imsplitbit: Exactly. We could make them Trove themed and sell them for profit with proceeds going to the OS foundation. :)
18:42:13 <denis_makogon> demorris, good approach, i think it's very significant since Trove will have multiple datastores
18:42:21 <amytron> with our trove logo
18:43:18 <denis_makogon> demorris, we could deal with it, you want to store type/version in metadata or in the backup model ?
18:43:41 <SlickNik> demorris: Sounds like a good idea. I haven't seen a bp for it.
18:43:47 <SlickNik> someone want to open one?
18:44:03 <demorris> denis_makogon: true, that might actually be better so then you can query it via Trove
18:44:20 <denis_makogon> demorris, so, store in the model ?
18:45:38 <demorris> well I suppose it depends on what we want to accomplish.  One of the main reasons for this is so that you can prevent a user from trying to restore a backup to the wrong datastore, but it could also be useful to help with filtering data stores that are valid
18:45:40 <denis_makogon> demorris, since backup models hold the instance_id we could always retrieve any data from instance model, if instance still exists
18:45:56 <demorris> it is possible that the instance may be deleted though
18:46:10 <denis_makogon> yes, thats what i say =)
18:46:31 <SlickNik> We do store the strategy in the model, and it's unlikely that different models share the same strategy, so there's that.
18:46:45 <denis_makogon> demorris, i'll vote for model instead of meta
18:47:38 <vipul> if i have a percona backup, and want to restore to maria .. that should be allowed
18:47:52 <demorris> denis_makogon: k, you want to BP it?
18:47:57 <vipul> it seems that a backup shouldn't be tied to a datastore, rather.. it should be tied to a 'restorer' or whatever
18:48:00 <demorris> it can get tricky too when you consider MySQL, MariaDB, and Percona…backups via XtraBackup are not strictly supported when backing up with one and restoring to another (but there are cases where it can work)
18:48:04 <SlickNik> vipul: Yes, if the strategy is the same, it's likely that the restore will work _across_ datastores.
18:48:31 <grapex> SlickNik: I think you're right- if the strategy is stored in the model that alone should work for validation
18:48:36 <denis_makogon> demorris, yeah, i could, but if i'll forget, could you do this ?
18:48:54 <vipul> so we'd need to someplace in code to tie a strategy to one or more datastores
18:48:59 <demorris> I think it should support restoring across types/versions, but should be up to operator on what they want to support and not support
18:49:04 <denis_makogon> #action File a BP for adding datastore type/version to backup model
18:49:10 <hub_cap> party time im back
18:49:34 <vipul> wait so why are we adding datastore type to backups now.. i'm confused
18:49:39 <SlickNik> vipul: yes, today this exists only in the ga.conf. But we might want to codify this some more.
18:49:58 <vipul> SlickNik: yea, mainly want to do validation on a restore
18:50:32 <denis_makogon> vipul, first approach - block from restoring instance with wrong datastore, that differs from datastore of the instance that was backuped
18:50:57 <demorris> yes, validation on a restore, and secondarily filtering per datastore (only show me backups for MongoDB, exclude all others")
18:51:00 <vipul> denis_makogon: we can derive that from the 'Backup stragey' already stored on the backup
18:51:29 <vipul> i guess i'm not a big fan do de-normalization.. we've got this info that can be derived in several ways
18:51:33 <denis_makogon> vipul, i guest it'll be the long way
18:51:45 <robertmyers> vipul: until you delete the instance
18:51:46 <denis_makogon> *i guess
18:51:52 <vipul> robertmyers: it's a soft delete
18:52:12 <vipul> trove can do a search for any instances that the backup originated from
18:52:27 <robertmyers> sure I gues
18:52:48 <demorris> so am I hearing we can already make the association?
18:52:54 <juice> can you drop the backup strategy from the backup model and replace it with the datastore reference...from there you could derive the backup strategy after it has been associated with the datastore
18:52:56 <denis_makogon> vipul, lets do not relay on soft delete
18:52:56 <robertmyers> so then all it would need is a view change
18:53:04 <robertmyers> on the details for a backup
18:53:28 <denis_makogon> robertmyers, agreed
18:53:44 <vipul> robertmyers: +1
18:53:52 <kevinconway> juice: so do we have to work on migration paths for changing backup methods?
18:53:54 <denis_makogon> so, theres two options:
18:53:59 <vipul> i agree that there are issues with relying on soft-deletes, because there may be truncates that a deployer wants to do
18:54:22 <vipul> juice: i think that's the same as what was beign suggested.. add a datastore reference to backups
18:54:27 <denis_makogon> 1. have an ability to retrieve type/version by backup_type.
18:54:47 <denis_makogon> 2. add datastore version and type into the backup model
18:55:00 <denis_makogon> approach: strict validation on restore/recover
18:55:46 <denis_makogon> let me file the BP, wiki page and ML for that, and then review it
18:55:48 <denis_makogon> ok ?
18:55:49 <vipul> denis_makogon: feel free to BP this, we can disucss it during BP review
18:56:04 <vipul> i would also put in robertmyers suggestion in the BP, which doesn't require any DB change
18:56:23 <SlickNik> I agree that this is something we should do (impl details aside).
18:56:28 <SlickNik> So let's file the bp.
18:56:53 <denis_makogon> robertmyers, i'll file it and then i'll ask you to update the whiteboard
18:57:03 <cp16net> ok
18:57:05 <denis_makogon> could i take last minutes ?
18:57:08 <robertmyers> denis_makogon: use the wiki
18:57:20 <denis_makogon> ok
18:57:37 <SlickNik> remember to use
18:57:40 <SlickNik> #link https://wiki.openstack.org/wiki/TroveBlueprint
18:58:04 <denis_makogon> i'd like to invite all of us into the discussion related to Point it time recovery
18:58:18 <hub_cap> denis_makogon: go go go, 3 min
18:58:42 <denis_makogon> i already filed the BP, did the draft implementation (which was done easily)
18:58:51 <denis_makogon> and sent the email
18:59:19 <denis_makogon> so, please, don't be the shy =)) review them and join the ML thread
18:59:36 <vipul> denis_makogon: can you conver teh google doc to wiki
18:59:44 <vipul> convert
18:59:49 <cp16net> +1 vipul
18:59:52 <kevinconway> then print out the HTML
18:59:56 <denis_makogon> vipul, yes, i'll do that
18:59:57 <kevinconway> feed it to an XLST template
19:00:00 <kevinconway> and generate markdown
19:00:02 <vipul> kevinconway +1
19:00:17 <hub_cap> yes all should be wiki
19:00:20 <hub_cap> we will review it on monday too
19:00:25 <demorris> I don't quite understand the issues with looking at point in time recovery based on what was stated on the ML.  It is true that there are tons of impl nuances across data stores, but the concept of the API to reference a point in time for a restore both on an existing and new instance is valid
19:00:29 <denis_makogon> also i'd like to point your attention onto the dblog feature, which wasn't even once reviewed since it was published
19:00:30 <vipul> and when we post to ML, i don't think it's necessary to copy / paste the entire thing.. i think you shoudl include an overview and then point people to the Wiki
19:00:39 <hub_cap> denis_makogon: plz add your log bp and your PIT bp to the bottom of the meeting page
19:00:45 <hub_cap> we will use that as the starting point for discussion
19:00:56 <hub_cap> ++ vipul
19:01:13 <denis_makogon> # link https://blueprints.launchpad.net/trove/+spec/mysql-point-in-time-recovery
19:01:33 <denis_makogon> #link https://blueprints.launchpad.net/trove/+spec/dbinstance-log
19:01:39 <denis_makogon> #link https://blueprints.launchpad.net/trove/+spec/mysql-point-in-time-recovery
19:01:47 <denis_makogon> #link https://wiki.openstack.org/wiki/TroveDBInstanceLogOperation
19:01:49 <hub_cap> good timing
19:01:54 <hub_cap> #endmeeting