| *** matsuhashi has joined #openstack-trove | 00:01 | |
| *** nosnos has joined #openstack-trove | 01:41 | |
| *** haomaiw__ has quit IRC | 02:18 | |
| *** haomaiwang has joined #openstack-trove | 02:18 | |
| *** ViswaV has joined #openstack-trove | 02:35 | |
| *** ViswaV_ has joined #openstack-trove | 02:35 | |
| *** coolsvap|afk is now known as coolsvap | 02:38 | |
| *** ViswaV has quit IRC | 02:39 | |
| *** matsuhashi has quit IRC | 03:31 | |
| openstackgerrit | Hou Ming Wang proposed a change to openstack/trove: Sort requirement files in alphabetical order https://review.openstack.org/77064 | 03:36 |
|---|---|---|
| *** nosnos has quit IRC | 03:49 | |
| *** eghobo has joined #openstack-trove | 03:49 | |
| *** ViswaV_ has quit IRC | 04:04 | |
| *** ViswaV has joined #openstack-trove | 04:04 | |
| *** haomai___ has joined #openstack-trove | 04:13 | |
| *** haomaiwang has quit IRC | 04:16 | |
| *** eghobo has quit IRC | 04:37 | |
| *** matsuhashi has joined #openstack-trove | 04:38 | |
| *** eghobo has joined #openstack-trove | 04:38 | |
| *** eguz has joined #openstack-trove | 04:40 | |
| *** eghobo has quit IRC | 04:44 | |
| *** nosnos has joined #openstack-trove | 04:48 | |
| *** haomai___ has quit IRC | 05:03 | |
| *** amytron has joined #openstack-trove | 05:15 | |
| *** haomaiwa_ has joined #openstack-trove | 05:22 | |
| *** amytron has quit IRC | 05:23 | |
| *** nosnos_ has joined #openstack-trove | 05:36 | |
| *** nosnos has quit IRC | 05:36 | |
| *** matsuhas_ has joined #openstack-trove | 06:00 | |
| *** matsuhashi has quit IRC | 06:03 | |
| openstackgerrit | Jenkins proposed a change to openstack/trove: Imported Translations from Transifex https://review.openstack.org/82721 | 06:21 |
| *** nosnos has joined #openstack-trove | 06:32 | |
| *** nosnos_ has quit IRC | 06:32 | |
| *** matsuhas_ has quit IRC | 06:37 | |
| *** matsuhashi has joined #openstack-trove | 06:37 | |
| *** matsuhashi has quit IRC | 06:37 | |
| *** matsuhashi has joined #openstack-trove | 06:38 | |
| *** shivam has quit IRC | 06:57 | |
| *** shivam has joined #openstack-trove | 06:58 | |
| *** PradeepChandani_ has joined #openstack-trove | 06:58 | |
| *** PradeepChandani has quit IRC | 06:58 | |
| *** flaper87|afk is now known as flaper87 | 07:17 | |
| *** sbfox has joined #openstack-trove | 07:21 | |
| *** ViswaV has quit IRC | 07:27 | |
| *** haomaiwa_ has quit IRC | 07:34 | |
| *** haomaiwa_ has joined #openstack-trove | 07:35 | |
| *** sbfox has quit IRC | 07:46 | |
| *** haomaiw__ has joined #openstack-trove | 07:47 | |
| *** haomaiwa_ has quit IRC | 07:50 | |
| *** eguz has quit IRC | 07:50 | |
| *** sbfox has joined #openstack-trove | 08:59 | |
| *** haomaiw__ has quit IRC | 09:03 | |
| *** haomaiwa_ has joined #openstack-trove | 09:03 | |
| *** haomaiw__ has joined #openstack-trove | 09:05 | |
| *** haomaiwa_ has quit IRC | 09:08 | |
| *** shivam has quit IRC | 09:11 | |
| *** shivam has joined #openstack-trove | 09:12 | |
| *** shivam_ has joined #openstack-trove | 09:22 | |
| *** shivam has quit IRC | 09:23 | |
| *** PradeepChandani_ has quit IRC | 09:23 | |
| *** PradeepChandani_ has joined #openstack-trove | 09:25 | |
| *** PradeepChandani_ has quit IRC | 09:35 | |
| *** shivam_ has quit IRC | 09:36 | |
| *** sbfox has quit IRC | 09:39 | |
| *** sbfox has joined #openstack-trove | 09:58 | |
| *** SushilKM has joined #openstack-trove | 10:11 | |
| *** sbfox has quit IRC | 10:22 | |
| *** sbfox has joined #openstack-trove | 10:40 | |
| *** matsuhashi has quit IRC | 10:40 | |
| *** matsuhashi has joined #openstack-trove | 10:41 | |
| *** SushilKM has quit IRC | 10:43 | |
| *** matsuhashi has quit IRC | 10:50 | |
| *** matsuhas_ has joined #openstack-trove | 10:52 | |
| *** coolsvap is now known as coolsvap|afk | 10:52 | |
| *** sbfox has quit IRC | 10:58 | |
| *** sbfox has joined #openstack-trove | 11:00 | |
| *** sbfox has quit IRC | 11:00 | |
| *** matsuhas_ has quit IRC | 11:00 | |
| *** sbfox has joined #openstack-trove | 11:01 | |
| *** SushilKM has joined #openstack-trove | 11:02 | |
| *** matsuhas_ has joined #openstack-trove | 11:04 | |
| *** SushilKM has quit IRC | 11:04 | |
| *** SushilKM has joined #openstack-trove | 11:05 | |
| *** sbfox has quit IRC | 11:12 | |
| *** matsuhas_ has quit IRC | 11:15 | |
| *** SushilKM has quit IRC | 11:15 | |
| *** matsuhashi has joined #openstack-trove | 11:16 | |
| *** sbfox has joined #openstack-trove | 11:23 | |
| *** SushilKM has joined #openstack-trove | 11:26 | |
| *** sbfox has quit IRC | 11:27 | |
| *** sbfox has joined #openstack-trove | 11:27 | |
| *** amytron has joined #openstack-trove | 11:39 | |
| *** amytron has quit IRC | 11:44 | |
| *** sbfox has quit IRC | 11:45 | |
| *** matsuhashi has quit IRC | 11:46 | |
| *** matsuhashi has joined #openstack-trove | 11:51 | |
| *** demorris has joined #openstack-trove | 11:54 | |
| *** sgotliv has joined #openstack-trove | 11:59 | |
| *** nosnos has quit IRC | 12:01 | |
| *** SushilKM has quit IRC | 12:02 | |
| openstackgerrit | Denis M. proposed a change to openstack/python-troveclient: Add point in time recovery https://review.openstack.org/77223 | 12:03 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Add point in time recovery https://review.openstack.org/77222 | 12:08 |
| *** sbfox has joined #openstack-trove | 12:12 | |
| *** pdmars has joined #openstack-trove | 12:17 | |
| *** demorris has quit IRC | 12:25 | |
| *** matsuhashi has quit IRC | 12:29 | |
| *** matsuhashi has joined #openstack-trove | 12:30 | |
| *** matsuhashi has quit IRC | 12:34 | |
| *** matsuhashi has joined #openstack-trove | 12:42 | |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Add point in time recovery https://review.openstack.org/77222 | 12:49 |
| *** freyes has joined #openstack-trove | 12:54 | |
| *** freyes has quit IRC | 12:58 | |
| *** sgotliv has quit IRC | 13:01 | |
| *** jcru has joined #openstack-trove | 13:05 | |
| *** matsuhashi has quit IRC | 13:06 | |
| *** sbfox has quit IRC | 13:10 | |
| *** matsuhas_ has joined #openstack-trove | 13:10 | |
| *** imsplitbit has quit IRC | 13:16 | |
| *** grapex has joined #openstack-trove | 13:22 | |
| *** achampion has quit IRC | 13:23 | |
| *** grapex has quit IRC | 13:25 | |
| *** grapex has joined #openstack-trove | 13:26 | |
| *** imsplitbit has joined #openstack-trove | 13:32 | |
| openstackgerrit | Denis M. proposed a change to openstack/python-troveclient: Add point in time recovery https://review.openstack.org/77223 | 13:36 |
| *** demorris has joined #openstack-trove | 13:38 | |
| *** matsuhas_ has quit IRC | 13:42 | |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow db instance conditional logging https://review.openstack.org/63789 | 13:50 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow log files audit https://review.openstack.org/64302 | 13:50 |
| *** demorris_ has joined #openstack-trove | 13:50 | |
| *** freyes has joined #openstack-trove | 13:51 | |
| *** matsuhashi has joined #openstack-trove | 13:52 | |
| *** demorris has quit IRC | 13:53 | |
| *** demorris_ is now known as demorris | 13:53 | |
| openstackgerrit | Deepika Goswami proposed a change to openstack/trove: Incorrect error message- user-access-revoke API https://review.openstack.org/86258 | 13:53 |
| *** matsuhashi has quit IRC | 13:54 | |
| *** jmontemayor has joined #openstack-trove | 13:54 | |
| *** yidclare has quit IRC | 13:56 | |
| *** robertmy_ has joined #openstack-trove | 14:05 | |
| *** denis_makogon has quit IRC | 14:05 | |
| *** robertmy_ has quit IRC | 14:07 | |
| *** robertmyers has joined #openstack-trove | 14:07 | |
| *** robertmyers has quit IRC | 14:08 | |
| *** denis_makogon has joined #openstack-trove | 14:08 | |
| *** sbfox has joined #openstack-trove | 14:08 | |
| *** robertmyers has joined #openstack-trove | 14:09 | |
| *** rwsu has joined #openstack-trove | 14:09 | |
| *** achampion has joined #openstack-trove | 14:10 | |
| *** robertmy_ has joined #openstack-trove | 14:11 | |
| *** robertm__ has joined #openstack-trove | 14:13 | |
| *** robertmy_ has quit IRC | 14:13 | |
| *** robertmyers has quit IRC | 14:13 | |
| *** robertm__ has quit IRC | 14:13 | |
| *** robertmyers has joined #openstack-trove | 14:14 | |
| *** robertmy_ has joined #openstack-trove | 14:16 | |
| *** robertmyers has quit IRC | 14:16 | |
| *** robertmyers has joined #openstack-trove | 14:18 | |
| *** robertmy_ has quit IRC | 14:18 | |
| *** robertmyers has quit IRC | 14:20 | |
| *** robertmyers has joined #openstack-trove | 14:20 | |
| *** robertmyers has quit IRC | 14:22 | |
| *** robertmyers has joined #openstack-trove | 14:23 | |
| *** Barker has joined #openstack-trove | 14:23 | |
| *** robertmyers has quit IRC | 14:25 | |
| *** robertmyers has joined #openstack-trove | 14:25 | |
| *** robertmy_ has joined #openstack-trove | 14:28 | |
| *** robertmyers has quit IRC | 14:30 | |
| *** robertmy_ has quit IRC | 14:30 | |
| *** robertmyers has joined #openstack-trove | 14:30 | |
| *** robertmyers has quit IRC | 14:32 | |
| *** robertmy_ has joined #openstack-trove | 14:32 | |
| *** robertmy_ has quit IRC | 14:33 | |
| *** robertmyers has joined #openstack-trove | 14:33 | |
| *** amytron has joined #openstack-trove | 14:34 | |
| *** robertmy_ has joined #openstack-trove | 14:35 | |
| *** robertm__ has joined #openstack-trove | 14:37 | |
| *** robertmy_ has quit IRC | 14:37 | |
| *** robertmyers has quit IRC | 14:38 | |
| *** robertm__ has quit IRC | 14:38 | |
| *** robertmyers has joined #openstack-trove | 14:39 | |
| *** Barker has quit IRC | 14:39 | |
| *** robertmyers has quit IRC | 14:41 | |
| *** robertmy_ has joined #openstack-trove | 14:41 | |
| *** mattgriffin has joined #openstack-trove | 14:41 | |
| *** Barker has joined #openstack-trove | 14:42 | |
| *** robertmy_ has quit IRC | 14:42 | |
| *** kevinconway has joined #openstack-trove | 14:46 | |
| *** thedodd has joined #openstack-trove | 14:59 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/trove: Switch over to FixedIntervalLoopingCall https://review.openstack.org/87288 | 15:02 |
| *** doddstack has joined #openstack-trove | 15:06 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/trove: Switch over to FixedIntervalLoopingCall https://review.openstack.org/87288 | 15:06 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow log files audit https://review.openstack.org/64302 | 15:07 |
| *** thedodd has quit IRC | 15:08 | |
| *** SnowDust has joined #openstack-trove | 15:11 | |
| *** sbfox has quit IRC | 15:13 | |
| openstackgerrit | Dirk Mueller proposed a change to openstack/trove: Switch over to FixedIntervalLoopingCall https://review.openstack.org/87288 | 15:15 |
| *** PierreRambaud has joined #openstack-trove | 15:15 | |
| *** NehaV has joined #openstack-trove | 15:16 | |
| *** SnowDust has quit IRC | 15:17 | |
| *** SnowDust has joined #openstack-trove | 15:22 | |
| *** sbfox has joined #openstack-trove | 15:23 | |
| *** coolsvap|afk is now known as coolsvap | 15:25 | |
| SnowDust | who wrote d sackheads.com stuff hehe :) read it today | 15:26 |
| SnowDust | coolsvap : did u also read http://sackheads.org/~bnaylor/spew/away_msgs.html | 15:33 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow db instance conditional logging https://review.openstack.org/63789 | 15:33 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Allow log files audit https://review.openstack.org/64302 | 15:33 |
| coolsvap | SnowDust: I have disabled my away messages, are my away msgs getting logged? | 15:35 |
| SnowDust | what I saw today : • coolsvap|afk New nick: coolsvap | 15:36 |
| coolsvap | SnowDust: its from my irc bouncer, it happens only twice a day when i am not connected, (not justifying :) ) I will see to it how i can remove that as well | 15:41 |
| *** freyes has quit IRC | 15:43 | |
| *** SnowDust has quit IRC | 15:47 | |
| *** SnowDust has joined #openstack-trove | 15:48 | |
| *** SnowDust has quit IRC | 15:53 | |
| *** ViswaV has joined #openstack-trove | 15:54 | |
| *** ViswaV_ has joined #openstack-trove | 15:54 | |
| *** ViswaV has quit IRC | 15:58 | |
| *** SnowDust has joined #openstack-trove | 16:01 | |
| *** eghobo has joined #openstack-trove | 16:03 | |
| *** rueb7363 has joined #openstack-trove | 16:03 | |
| *** SnowDust has quit IRC | 16:07 | |
| *** robertmyers has joined #openstack-trove | 16:39 | |
| *** sbfox has quit IRC | 16:50 | |
| *** sbfox has joined #openstack-trove | 16:50 | |
| *** harlowja_away is now known as harlowja | 16:54 | |
| *** SushilKM has joined #openstack-trove | 16:59 | |
| *** sriram_tesora has joined #openstack-trove | 17:01 | |
| *** Barker has quit IRC | 17:04 | |
| *** ViswaV_ has quit IRC | 17:06 | |
| *** ViswaV has joined #openstack-trove | 17:06 | |
| *** amcrn has joined #openstack-trove | 17:11 | |
| *** eghobo has quit IRC | 17:12 | |
| *** eguz has joined #openstack-trove | 17:12 | |
| *** eguz has quit IRC | 17:12 | |
| *** eghobo has joined #openstack-trove | 17:13 | |
| *** ViswaV has quit IRC | 17:19 | |
| *** yogesh has joined #openstack-trove | 17:19 | |
| *** demorris has quit IRC | 17:23 | |
| *** demorris has joined #openstack-trove | 17:24 | |
| *** ViswaV has joined #openstack-trove | 17:25 | |
| *** denis_makogon_ has joined #openstack-trove | 17:26 | |
| *** SnowDust has joined #openstack-trove | 17:28 | |
| *** khyati has joined #openstack-trove | 17:30 | |
| SlickNik | Hi Trove folks. | 17:31 |
| SlickNik | The bp meeting is in about 30 mins, so please take a few minutes to go through the bps at https://wiki.openstack.org/wiki/Meetings/TroveMeeting (if you already haven't done so). | 17:32 |
| SlickNik | Thanks! | 17:32 |
| *** yidclare has joined #openstack-trove | 17:32 | |
| denis_makogon_ | SlickNik, hi =) | 17:37 |
| *** denis_makogon has quit IRC | 17:37 | |
| *** denis_makogon_ is now known as denis_makogon | 17:37 | |
| SlickNik | hi denis_makogon | 17:37 |
| *** dmakogon_ has joined #openstack-trove | 17:38 | |
| denis_makogon | SlickNik, what's up ? | 17:38 |
| denis_makogon | SlickNik, may i congratulate you with PTL position ? =) | 17:39 |
| SlickNik | denis_makogon: Thanks! | 17:39 |
| vipul | that is quite an agenda | 17:40 |
| amrith | vipul: I'm planning on making my part by tabling my bp. | 17:41 |
| *** sgotliv has joined #openstack-trove | 17:42 | |
| denis_makogon | annashen, ping | 17:43 |
| annashen | denis_makogon: pong | 17:44 |
| denis_makogon | annashen, saw you pinged my at friday, i guess | 17:44 |
| denis_makogon | annashen, i was out | 17:44 |
| denis_makogon | annashen, what's up ? | 17:44 |
| annashen | i figured | 17:44 |
| annashen | was trying to discuss two bp with you last friday | 17:45 |
| denis_makogon | annashen, we have 15 mins now | 17:45 |
| denis_makogon | annashen, which questions you want to discuss ? | 17:46 |
| *** sbfox has quit IRC | 17:47 | |
| *** michael-yu has joined #openstack-trove | 17:47 | |
| annashen | just updated the agenda | 17:48 |
| SlickNik | So one of the things I want to discuss, and the Wednesday meeting is appropriate for this, is how we can make this bp process more efficient. | 17:49 |
| denis_makogon | SlickNik, which one ? | 17:50 |
| denis_makogon | annashen, please move your BP at the end of the list, this is the queue | 17:51 |
| SlickNik | Have some set of fixed outcomes for the bps (like approved, approved with minor edits, needs work before resubmission, not approved) | 17:51 |
| *** amytron_ has joined #openstack-trove | 17:51 | |
| SlickNik | Just a heads up, I'll ping the channel when I have some more information regarding it. | 17:52 |
| SlickNik | denis_makogon: the process, not any one bp in particular. | 17:52 |
| denis_makogon | SlickNik, ah, get it =) | 17:52 |
| *** amytron has quit IRC | 17:52 | |
| *** amytron_ is now known as amytron | 17:52 | |
| annashen | denis, both of our bp is related, i think they are better to be discussed together. if you do not mind, we can discuss them at the end of the meeting -- since i am the last one | 17:52 |
| denis_makogon | annashen, of course =) | 17:53 |
| SlickNik | I've also set up an etherpad page for people to take notes against the specific bps: https://etherpad.openstack.org/p/trove-bp-2014-04-14 | 17:54 |
| *** coolsvap is now known as coolsvap|afk | 17:54 | |
| *** NehaV has quit IRC | 17:54 | |
| denis_makogon | SlickNik, good idea | 17:55 |
| SlickNik | Okay, let's start. | 17:58 |
| denis_makogon | #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting | 17:58 |
| SlickNik | core folks, around? | 17:59 |
| vipul | o/ | 17:59 |
| grapex | o/ | 17:59 |
| amcrn | o/ | 18:00 |
| SlickNik | Datastore Capabilities [k-pom] (https://blueprints.launchpad.net/trove/+spec/capabilities%29 | 18:00 |
| amrith | \o/ | 18:00 |
| esmute | link is not worky | 18:00 |
| SlickNik | Datastore Capabilities [k-pom] https://blueprints.launchpad.net/trove/+spec/capabilities%29 | 18:00 |
| *** SushilKM is now known as Congrats | 18:00 | |
| SlickNik | ah paren | 18:00 |
| SlickNik | https://launchpad.net/trove/+spec/capabilities | 18:01 |
| SlickNik | try that | 18:01 |
| * grapex waiting for SlickNik to yell "fail!" and hit a gong | 18:01 | |
| amrith | wprls | 18:01 |
| amrith | works | 18:01 |
| *** Congrats has quit IRC | 18:01 | |
| peterstac | I guess in etherpad you need to put a space before the closing bracket | 18:01 |
| annashen | o/ | 18:01 |
| *** SushillKM has joined #openstack-trove | 18:01 | |
| grapex | So- work already started on this one and we discussed it at the meetup | 18:02 |
| grapex | k-pom: what's changed since then? | 18:02 |
| denis_makogon | is Kaleb in ? | 18:02 |
| grapex | imsplitbit: yt? | 18:02 |
| SlickNik | Looking at the blueprint, it seems like nothing has really changed since the last time this was approved. | 18:03 |
| denis_makogon | agreed | 18:03 |
| denis_makogon | k-pom, so, what's the difference ? | 18:03 |
| robertmyers | hub_cap: asked for it to go back to the meeting | 18:03 |
| robertmyers | for approval | 18:03 |
| robertmyers | in the new process | 18:03 |
| SlickNik | Perhaps it was just added for completeness sake? | 18:03 |
| SlickNik | Gotcha. | 18:04 |
| grapex | Ah | 18:04 |
| vipul | so just looking at the API.. is there supposed to be a value that gets returned for a capability? | 18:04 |
| vipul | so ther eis a capability "VolumeSupport" that comes back.. | 18:04 |
| grapex | vipul: Yes, I think so | 18:04 |
| vipul | how does an Admin know whether it's true/false | 18:04 |
| vipul | likewise for creating a capability | 18:04 |
| grapex | IIRC Kaleb said he had multiple pull requests lined up for this | 18:04 |
| esmute | the admin will have to reset trove when the capabilities are changed too | 18:05 |
| amcrn | vipul: see https://review.openstack.org/#/c/83503/7/trove/datastore/models.py | 18:05 |
| SlickNik | vipul: there are 2 GET calls. | 18:05 |
| robertmyers | So I think that this allows Trove to have two or more datastores with different settings | 18:05 |
| k-pom | yeah, sorry - I was grabbing food | 18:05 |
| vipul | also we should probably also talk a bit about the values that come from conf vs. from the capabitlites table | 18:05 |
| SlickNik | One returns all capabilities, the other returns only enabled ones, I think | 18:06 |
| robertmyers | one has volume support and the other doesn't | 18:06 |
| vipul | robertmyers: +1 i like that we can associate this to a datastore | 18:06 |
| k-pom | in answer to the earlier question - Nothing much as changed. wording and verbiage mostly | 18:06 |
| SlickNik | esmute: what do you mean by reset trove? | 18:07 |
| denis_makogon | SlickNik, drop down the backend | 18:07 |
| denis_makogon | i guess | 18:07 |
| esmute | SlickNik: When capabilities changes... going from not supporting volume to supporting it... trove will need a restart | 18:07 |
| amrith | maybe the author could reply? | 18:07 |
| amrith | thx | 18:08 |
| k-pom | Why would trove need a restart? | 18:08 |
| denis_makogon | esmute, why is that, since we're working this dynamic backend we don't need to restart trove each time when new capability would come | 18:09 |
| *** NehaV has joined #openstack-trove | 18:09 | |
| SlickNik | esmute: ah okay. I think since this is in the DB, it probably wouldn't need a restart. | 18:09 |
| vipul | esmute: I think the idea is that those values would be pulled out of conf files | 18:09 |
| esmute | im guessing im misunderstanding the feature... is it not changing the conf value from trove_volume_support from true to false? | 18:09 |
| denis_makogon | esmute, it's not | 18:10 |
| *** sbfox has joined #openstack-trove | 18:10 | |
| k-pom | no, we are removing the config value and making it use a more dynamic, database stored value | 18:10 |
| k-pom | *config value from the flat file | 18:10 |
| denis_makogon | esmute, this feature about letting end-user know with what kind of capabilities he can work in general or per datastore | 18:11 |
| SlickNik | Okay, I move we approve this. Based on our past approval, and the fact that only verbiage has changed here. | 18:11 |
| esmute | so CONF.trove_volume_support will always refresh the new value | 18:11 |
| denis_makogon | esmute, if that's the case, we would need to drop this | 18:11 |
| esmute | ok.. i think i need to read up more about the feature. | 18:11 |
| k-pom | no. that will be replaced with something like ("trove_volume_support" in datastore.capabilities) | 18:11 |
| *** SushillKM has quit IRC | 18:12 | |
| denis_makogon | so, can we move on ? | 18:12 |
| SlickNik | vipul / grapex / amcrn: Agree to approve? | 18:13 |
| esmute | ok.. ill just look at the code in the patch to get a better understanding.. dont want to hold this meeting | 18:13 |
| grapex | SlickNik: +1 | 18:13 |
| amcrn | SlickNik: assuming my comments in the review are agreed upon, i approve. | 18:13 |
| vipul | yup, i'll review the patches, and add any issues i ahve there | 18:13 |
| SlickNik | Thanks | 18:13 |
| SlickNik | Descriptions to Datastore Configuration Group Parameters [cp16net] (https://blueprints.launchpad.net/trove/+spec/add-descriptions-to-config-parameters-api%29 | 18:13 |
| cp16net | yes | 18:14 |
| esmute | #link https://blueprints.launchpad.net/trove/+spec/add-descriptions-to-config-parameters-api | 18:14 |
| amrith | a comment: could this BP use the template we agreed upon in Austin. Thx. | 18:14 |
| esmute | oops.. we dont have a bot here dont we | 18:14 |
| cp16net | overview of this is that there has been a request to add some kind of "help" text on each of the configuration parameters | 18:15 |
| cp16net | so that a UI can give some details on them | 18:15 |
| denis_makogon | cp16net, do we really need to store in in the backend ? | 18:15 |
| grapex | amrith: about that Bp template- it looks like this is just referencing a piece of the original blueprint that we didn't do | 18:15 |
| cp16net | amrith: yes grapex is correct | 18:16 |
| amrith | grapex: ok, sorry I didn't have that context. | 18:16 |
| denis_makogon | cp16net, description is static text, nothing would change among X releases of the database | 18:16 |
| SlickNik | cp16net: so this is a bp to fixup the previous bp to add the help text? | 18:16 |
| vipul | denis_makogon: how else would you get the actual string | 18:16 |
| grapex | amrith: no problem. I agree, I like the template too. | 18:16 |
| cp16net | denis_makogon: if this is not stored in the backend then each time we change parameters or make them custom for different deployments it would require massive changes in the UI | 18:16 |
| cp16net | SlickNik: yes it is something we missed before | 18:17 |
| cp16net | i overlooked it when implemented the feature before | 18:17 |
| dougshelley66 | so really this is a bug? | 18:17 |
| denis_makogon | vipul, there're two options: DB and file, which is not quite good | 18:17 |
| cp16net | dougshelley66: i talked with SlickNik about it being a bug or BP | 18:18 |
| dougshelley66 | ah ok | 18:18 |
| cp16net | and i had already created the Bp for it | 18:18 |
| denis_makogon | so, if description should be stored at the backend than fine | 18:18 |
| cp16net | so we decided to just use it | 18:18 |
| *** NehaV has quit IRC | 18:18 | |
| vipul | denis_makogon: Yea i think it makes sense for it to go into the DB | 18:18 |
| vipul | I am good with this change | 18:18 |
| denis_makogon | vipul, so am i | 18:18 |
| SlickNik | IIRC: amcrn had some concern about localization / internationalization? | 18:19 |
| *** doddstack has quit IRC | 18:19 | |
| cp16net | denis_makogon: vipul: there is anotehr BP already being worked on that puts all this data for coonfig params in the db | 18:19 |
| SlickNik | don't recall exactly. | 18:19 |
| cp16net | yeah and we talked a bit about it | 18:19 |
| denis_makogon | cp16net, yes, and that's more than cool as for me | 18:19 |
| *** doddstack has joined #openstack-trove | 18:19 | |
| cp16net | denis_makogon: ttie | 18:19 |
| *** NehaV has joined #openstack-trove | 18:19 | |
| amrith | Who would the consumer of this information be? | 18:19 |
| cp16net | amrith: the api user | 18:20 |
| denis_makogon | SlickNik, i think we could deal with translations among all descriptions | 18:20 |
| cp16net | be that a UI or direct api access | 18:20 |
| denis_makogon | just need to dig how gettextutils work with translations | 18:20 |
| amrith | cp16net, SlickNick: the config parameter name and value and description will all have i18n issues in that case, no? | 18:20 |
| cp16net | name and value shouldnt | 18:20 |
| cp16net | description will | 18:21 |
| robertmyers | amrith: config names will not change | 18:21 |
| cp16net | depending on lanuage | 18:21 |
| amrith | yes, my point exactly | 18:21 |
| denis_makogon | robertmyers, agreed | 18:21 |
| kevinconway | so would the descriptions be cannonical or provided by the deployer? | 18:21 |
| grapex | If the description lives in the db, then whatever populates it will need to be the language agnostic piece right? | 18:21 |
| grapex | kevinconway: +1 | 18:21 |
| cp16net | grapex: yes it will need to be updated | 18:21 |
| amrith | and databases (like Oracle and MySQL) have taken the position that configuration parameters and values, and things like their descriptions are not i18n'ed | 18:21 |
| denis_makogon | amcrn, databases are well known with english, not russian, or hindi | 18:21 |
| amrith | so this should be fine, no? | 18:21 |
| cp16net | and can be updated once its in the db | 18:21 |
| grapex | If we have anything canonical we'll just make that driven by the .po files | 18:22 |
| denis_makogon | amrith, we're not the mysql or oracle, we're something above them, and that's why we can do more | 18:22 |
| grapex | say if we used a script in trove/contrib to populate them | 18:22 |
| robertmyers | well the PO files need a text to translate, it can't use the text in the DB | 18:22 |
| cp16net | grapex: yeah amcrn and i were talking about if any other projects used .po files for something similar like these descriptions going into the DB | 18:22 |
| denis_makogon | grapex, populates from the backend ? | 18:22 |
| cp16net | and we couldnt think of any at the time | 18:23 |
| amrith | cp16net: agreed | 18:23 |
| amrith | this seems fine | 18:23 |
| SlickNik | cp16net / amrith: I think we're good with that approach. | 18:23 |
| amrith | concur | 18:23 |
| denis_makogon | SlickNik, agreed | 18:23 |
| cp16net | SlickNik: ok | 18:23 |
| SlickNik | I'm fine approving this. | 18:24 |
| kevinconway | i'm also curious about the scope of a description. is it simply the text from datastore docs or suggestions for how to use it as well? | 18:24 |
| cp16net | i wish amcrn was around to pipe in | 18:24 |
| SlickNik | grapex / vipul / amcrn: good? | 18:24 |
| amcrn | i'm here, just don't have anything new/breaking to add | 18:24 |
| vipul | +1 | 18:24 |
| cp16net | hehe ok :-P | 18:24 |
| amcrn | :) | 18:24 |
| amcrn | +1 | 18:24 |
| denis_makogon | kevinconway, seems like it'll be just a text, depends on how admin uses it | 18:24 |
| grapex | SlickNik: +1 | 18:24 |
| SlickNik | Okay, approved. Let's move on. | 18:24 |
| kevinconway | denis_makogon: that's why i asked where they came from (trove vs deployer)) | 18:24 |
| SlickNik | Categorize the trove-manage commands [cp16net] https://blueprints.launchpad.net/trove/+spec/categorize-the-trove-manage-commands | 18:24 |
| cp16net | yeah ideally deployer will have to maintain their own list of params they might want to support and import them in the db and at that time they can make the descirptions what evre they want | 18:25 |
| robertmyers | cp16net: I think this need to be in the new format | 18:25 |
| cp16net | ok this one is to clean up the trove-mange manage cmd | 18:26 |
| grapex | For a second I thought this was discussing the client and my heart skipped a beat | 18:26 |
| grapex | robertmyers: What's the new format? | 18:26 |
| cp16net | oh poo i thought i did it ... | 18:26 |
| amrith | for bp's | 18:26 |
| grapex | Oh yeah | 18:26 |
| imsplitbit | grapex: sorry I'm on my laptop and don't have this window on my main desktop | 18:26 |
| imsplitbit | whats up? | 18:26 |
| denis_makogon | #link https://gist.github.com/cp16net/9278846 | 18:26 |
| grapex | imsplitbit: meeting. But k-pom's bp already got approved so you're good. :) | 18:27 |
| imsplitbit | ahh | 18:27 |
| vipul | wait.. so i thought the (project)-manage scripts were being deprecated | 18:27 |
| imsplitbit | ok thanks | 18:27 |
| imsplitbit | whas he not on for that? | 18:27 |
| amcrn | long-term we should look into resurrecting the the idea of turning the manage commands into an api (https://review.openstack.org/#/c/69408/) | 18:27 |
| imsplitbit | he probably didn't know he needed to be :) | 18:27 |
| vipul | in favor of doing the admin things in the main cli | 18:27 |
| cp16net | vipul: is that true? | 18:27 |
| grapex | imsplitbit: he got on | 18:27 |
| imsplitbit | oh ok | 18:27 |
| imsplitbit | my son was sick | 18:27 |
| imsplitbit | we were at the doctors office most of the morning | 18:27 |
| cp16net | well does that mean like db_sync and upgrade are gone? | 18:27 |
| vipul | well i don't know if there is an official stance on it or not. But i've seen novaclient have a ton more admin things in it | 18:27 |
| grapex | imsplitbit: Sorry to hear that... :( | 18:27 |
| denis_makogon | cp16net, i don't think so | 18:28 |
| grapex | vipul: Ugh... | 18:28 |
| cp16net | if its admin api sure | 18:28 |
| vipul | db_sync maybe not | 18:28 |
| grapex | Well it does make a bit more sense to put them in the mgmt api I guess | 18:28 |
| cp16net | but some of these could go either way | 18:28 |
| grapex | it's just much more work to add stuff there | 18:28 |
| vipul | but things like datastore mgmt, etc.. may just make sense as admin API? | 18:28 |
| grapex | And usually an admin will have the ability to run the manage commands anyway | 18:28 |
| grapex | vipul: I think datastore *does* | 18:28 |
| cp16net | yeah this is just to make the manage cmd similar to the other projects | 18:28 |
| SlickNik | vipul: +1 | 18:29 |
| grapex | that was one I raised an eyebrow on originally | 18:29 |
| cp16net | if you use nova-manage you know what i mean | 18:29 |
| grapex | my monocle dropped into my tea | 18:29 |
| vipul | lol | 18:29 |
| amrith | solution: drink coffee | 18:29 |
| denis_makogon | grapex, if that's the case, db_* operations also should be the part of the /mgmt | 18:29 |
| kevinconway | yeah, cp16net having the nova-manage commands in the nova client makes things very nice | 18:29 |
| grapex | btw for anyone who hasn't met us all members of core wear monocles as an affectation | 18:29 |
| robertmyers | denis_makogon: how can you db_sync in the api | 18:29 |
| imsplitbit | grapex: I believe it | 18:29 |
| robertmyers | if the api need a DB to start | 18:30 |
| imsplitbit | I picture you with a gold one | 18:30 |
| imsplitbit | and a pipe | 18:30 |
| grapex | robertmyers: +1 | 18:30 |
| vipul | db_sync is probably the only thing we need to leave in trove-manage | 18:30 |
| denis_makogon | robertmyers, i guess another route that flushes the backend | 18:30 |
| vipul | that's like install-time stuff | 18:30 |
| amcrn | well, and db_downgrade and db_upgrade | 18:30 |
| SlickNik | cp16net: Can you look into this a bit more? Keeping in mind that we might want to have a separate management API? | 18:30 |
| denis_makogon | robertmyers, i think it's possible | 18:30 |
| robertmyers | denis_makogon: trove wont start | 18:30 |
| vipul | but anything that isn't install-time.. probably doesn't need to live there | 18:30 |
| cp16net | SlickNik: ok | 18:30 |
| grapex | vipul: Maybe we should just add some stuff to the mgmt api and be more judicial about what goes into trove-manage in the future | 18:30 |
| *** shakayumi has joined #openstack-trove | 18:30 | |
| amcrn | cp16net: if you didn't see my link above, ashestakov did some preliminary work on a mgmt api for datastores @ https://review.openstack.org/#/c/69408/ | 18:31 |
| cp16net | just wanted to make sure we were off in our own land of manage cmds :-P | 18:31 |
| kevinconway | robertmyers: make trove drop all tables and db_sync on each boot | 18:31 |
| denis_makogon | robertmyers, i mean clean the data but leave the tables structure | 18:31 |
| *** shakayumi has quit IRC | 18:31 | |
| grapex | vipul: That's probably a good rule | 18:31 |
| SlickNik | cp16net: Also update the BP to use the new template format? | 18:31 |
| vipul | grapex: +1 - it sucks having several different CLIs to do admin things | 18:31 |
| denis_makogon | amcrn, i'll ping ashestackov | 18:31 |
| amcrn | denis_makogon: great, thanks | 18:31 |
| vipul | kevinconway: +1 | 18:31 |
| vipul | ;) | 18:31 |
| SlickNik | lol | 18:31 |
| SlickNik | cp16net: Thanks! | 18:31 |
| denis_makogon | amcrn, possibly i'll pick his task, 'cuz he's now at the other project | 18:32 |
| grapex | vipul: Yeah, I think you're right. Install time is a good delimiter for the trove-manage command | 18:32 |
| cp16net | ok it sounds like this BP will be defered | 18:32 |
| kevinconway | cp16net: oh the bugs that men file live after them, but the BP are oft deferred with their bones? | 18:32 |
| grapex | What's funny is, the CLI for Trove was originally like this | 18:32 |
| SlickNik | cp16net: I'm inclined to defer it; come back when you're ready with more info. | 18:32 |
| grapex | but the manage command wasn't- and somehow in both cases we were off from Nova and other projects | 18:33 |
| SlickNik | grapex: Yeah, I remember the days. | 18:33 |
| cp16net | yup | 18:33 |
| SlickNik | amcrn / grapex / vipul: okay to defer? | 18:33 |
| cp16net | thats fine with me | 18:33 |
| grapex | SlickNik: +1 to defer | 18:33 |
| amcrn | +1 to defer | 18:33 |
| vipul | +1 | 18:33 |
| SlickNik | Okay, thanks cp16net | 18:33 |
| SlickNik | Moving on. | 18:33 |
| SlickNik | Point in time recovery [denis_makogon] https://blueprints.launchpad.net/trove/+spec/point-in-time-recovery | 18:33 |
| denis_makogon | #link https://blueprints.launchpad.net/trove/+spec/point-in-time-recovery | 18:33 |
| cp16net | i'll chat you guys later about it | 18:33 |
| denis_makogon | this one was re-written, thanks to robertmyers | 18:34 |
| SlickNik | (aside: thanks to whoever fixed up the links!) | 18:34 |
| denis_makogon | approach was changed | 18:34 |
| denis_makogon | when user wants to recover at any point of time he'll receive new instance | 18:34 |
| SlickNik | So I had 2 main concerns with this one the last time it came up: | 18:35 |
| SlickNik | 1. What was initially proposed was not "point in time" recovery since you couldn't restore your db to a point in time | 18:35 |
| *** SnowDust has quit IRC | 18:35 | |
| SlickNik | 2. We were overwriting a customer instance which is potentially dangerous, and could cause a loss of data. | 18:35 |
| denis_makogon | 1. any point of time: user can mention the point of time and trove will find the closest backuped data to this point of time and then restore it to the new instance | 18:36 |
| denis_makogon | 2. now we're not overriding the data at current instance | 18:36 |
| amcrn | there's no indication in the blueprint as to how a user will be able to list the available backups and find a point in time backup they're comfortable with. POST'ing and hoping that the time you want and the time available is not far apart is not really acceptable. | 18:36 |
| amrith | so it isn't really point in time (in the industry standard sense of the word). | 18:36 |
| denis_makogon | instead of this we're provisioning new one with closest to the point of time data | 18:36 |
| SlickNik | denis_makogon: What if the "closest backup" was 30 days old? | 18:36 |
| SlickNik | That's not point in time recovery. | 18:36 |
| dougshelley66 | SlickNik, amrith +1 | 18:37 |
| kevinconway | or is it that the first impl is the closest until true point-in-time? | 18:37 |
| vipul | denis_makogon: I don't think we want to do something that says.. we'll get you close enough.. how do we know that's good enough for the user | 18:37 |
| robertmyers | I think this is the best we can do | 18:37 |
| amrith | so, to the point about "first impl", it would be good to know what the driver for this feature is | 18:37 |
| amrith | is it something that a user cannot accomplish by listing backups? | 18:37 |
| amrith | and picking one to restore from? | 18:38 |
| robertmyers | eventually we'd like to have the bin logs stored so that we could roll forward or backward | 18:38 |
| amrith | second: what of the case (coming soon to a theater near you) of a clustered system | 18:38 |
| cp16net | without using the binary log i think this is the best we can do for mysql | 18:38 |
| grapex | robertmyers: I saw we wait until then before we start | 18:38 |
| amrith | how would this play in a clustered or replicated system | 18:38 |
| esmute | does the instance need to be around for this to work? | 18:38 |
| amrith | Finally, Further, as written it appears to be MySQL specific. | 18:38 |
| amrith | As we discussed in Austin, it would be worthwhile moving forward if we designed features with a view to commonality across datastores. | 18:38 |
| amrith | This is a good idea but maybe worthwhile looking at a phased approach where the initial phases would build the framework and later stages the implementations. | 18:38 |
| esmute | meaning, what if the instance is 'deleted', how can you come up with the recoverd_from_instance? | 18:39 |
| denis_makogon | esmute, no, we need only it's attributes | 18:39 |
| denis_makogon | esmute, even if instance was soft-deleted | 18:39 |
| SlickNik | robertmyers: I agree, it's the closest we can do without saving the binlogs; but I'm questioning how valuable doing this would be. | 18:39 |
| amrith | SlickNik: +1 | 18:39 |
| vipul | SlickNik: +1 why don't we work on figuring out how to save binlogs instead | 18:39 |
| amcrn | +1 | 18:40 |
| kevinconway | oh boy. bin logs are fun | 18:40 |
| esmute | denis_makogon: yes if the instance is soft deleted, the user still cant see the instance to populate this field | 18:40 |
| denis_makogon | vipul, this feature is general for all datastores, instead of bin logs | 18:40 |
| amrith | so, are we resigned to make this a MySQL specific feature? | 18:40 |
| SlickNik | If we don't make any guarantees on how old the backup would be; as a customer I'd probably be safer restoring from a known backup anyway. | 18:40 |
| vipul | amrith: I don't think that's the intent.. but that's the minimum needed for at least MySQL to do point-in-time recovery.. I don't know what the analogous would be for other datastores | 18:41 |
| grapex | Ok, so talking to robertmyers I think this is a convience method so if someone is in a crisis situation they don't have to search the list themselves and figure out which one to restore | 18:41 |
| grapex | it would make more sense if there were at least scheduled backups at a semi-regular interval | 18:41 |
| grapex | It should be called something else | 18:42 |
| amcrn | grapex: i don't really buy that scenario; in any real disaster recovery scenario you'd make sure you know exactly what you're backing up | 18:42 |
| robertmyers | It also prepopulates the create POST with the same values of the existing instance | 18:42 |
| vipul | grapex: so then why do we need a whole new API? | 18:42 |
| grapex | like "easy-restore" or something- it might make more sense later | 18:42 |
| amrith | so grapex: we would pick one and restore? there are at least two use cases around that. One is most recent BEFORE point in time, and second is most recent AFTER point in time. | 18:42 |
| amcrn | sorry, "what you're restoring"* | 18:42 |
| amrith | I've seen value in both | 18:42 |
| denis_makogon | grapex, please suggest the another name for the feature | 18:42 |
| vipul | grapex: i think if that was desired.. then you could just implement 'restore' with an instance id or something instead of backup-id | 18:42 |
| amrith | grapex: so which is it? | 18:42 |
| grapex | I have to say this kind of API call doesn't seem to be the kind of thing we offer so far- it's a bit too specific | 18:43 |
| robertmyers | I vote instance-restore | 18:43 |
| grapex | robertmyers: Would it be better to just have an option for "restore latest?" | 18:43 |
| robertmyers | that would be the default | 18:43 |
| grapex | that is semi-specific without gauranteeing a specific point in time | 18:43 |
| grapex | vipul: +1 | 18:43 |
| kevinconway | so are we saying we don't want PIT and want most recent or the other way around? | 18:44 |
| denis_makogon | grapex, "restore latest" or "restore closest to ..." | 18:44 |
| grapex | So... this seems like another idea that is def. not point in time | 18:44 |
| amcrn | agreed | 18:44 |
| amrith | grapex: +1 | 18:44 |
| grapex | this is "last in line" | 18:44 |
| denis_makogon | grapex, that's why i asked for the suggestion like a week ago | 18:44 |
| kevinconway | but from what i read in the BP the API is point in time, just not the implemented behaviour | 18:44 |
| robertmyers | denis_makogon: you can also rename it :) | 18:45 |
| amrith | out of curiousity, what's driving this feature? right now the introduciton says it is because soemone doesn't want to have a hard covnersation with their manager. | 18:45 |
| amrith | but, is there some real use of this similification? | 18:45 |
| robertmyers | well, once there are automated backups it will make more sense | 18:46 |
| vipul | amrith: +1 .. I don't see why a DBA would choose do this blindly | 18:46 |
| denis_makogon | amrith, instances population for manual replication set organization | 18:46 |
| grapex | robertmyers : seems like you're arguing for a totally different bp | 18:46 |
| grapex | amrith: LOL! | 18:46 |
| robertmyers | grapex: well, this is part of the way we want to go | 18:46 |
| SlickNik | amrith: I'm not sure. I'm with amcrn on this one. If I were a dba, I don't think I'd use this API in a disaster recovery scenario, since there's actually no guarantee on how old of a backup this would use to do the restore. | 18:46 |
| grapex | amrith: We need more trove API calls to get people out of conversations with their managers | 18:47 |
| robertmyers | we also need a true point in time | 18:47 |
| grapex | I don't think this will be approved at this... point in time | 18:47 |
| robertmyers | and automated backups to achieve tha | 18:47 |
| vipul | if presented in an UI, you're likely going to have a drop-down anyway that lists all your backups.. | 18:47 |
| SlickNik | grapex | 18:47 |
| SlickNik | lol | 18:47 |
| denis_makogon | robertmyers, agreed with automated tasks we would have like "the most closest backup" and we would have N points of time represented by the each backup | 18:47 |
| esmute | grapex: lol | 18:47 |
| grapex | let's move on guys- I don't think the bp is ready | 18:47 |
| SlickNik | I do buy robertmyers point that this would be more useful if we had schedule automated backups. | 18:47 |
| amrith | if someone could stand up and point to a real DBA who would accept "closest backup", I'll relent | 18:48 |
| grapex | and gals | 18:48 |
| robertmyers | SlickNik: we can table it until then | 18:48 |
| amrith | grapex: +1 | 18:48 |
| vipul | I vote to defer until there is a real use-case and/or real point-in-time | 18:48 |
| amcrn | +1 to defer | 18:48 |
| kevinconway | amrith: define "real" DBA | 18:48 |
| SlickNik | +1 to defer | 18:48 |
| SlickNik | let's move on | 18:48 |
| *** SnowDust has joined #openstack-trove | 18:48 | |
| SlickNik | Data volume snapshot [denis_makogon] https://blueprints.launchpad.net/trove/+spec/volume-snapshot | 18:48 |
| denis_makogon | that's one also was rewritten according to given points | 18:49 |
| denis_makogon | not cinder snapshoting is the another way(strategy) to backup the data | 18:49 |
| denis_makogon | common for all datastores | 18:49 |
| vipul | so we're just adding a new backup_type that involves Cinder? | 18:50 |
| denis_makogon | vipul, eys | 18:50 |
| denis_makogon | vipul, involves the Cinder as backup tool and as Storage | 18:50 |
| SlickNik | Yes, I think that's the idea. | 18:50 |
| cp16net | this seems good to me | 18:50 |
| robertmyers | I like it as well | 18:50 |
| grapex | Sounds good | 18:51 |
| SlickNik | From last week IIRC, we decided not to have API creep and use the same API | 18:51 |
| cp16net | one q | 18:51 |
| SlickNik | Just another strategy | 18:51 |
| denis_makogon | SlickNik, yes | 18:51 |
| vipul | this will be invoked from the Guest correct? | 18:51 |
| denis_makogon | vipul, yes | 18:51 |
| amrith | denis_makogon: Will this require shutdown/reboot of trove instance? | 18:51 |
| cp16net | do cinder snapshots get stored in swift? | 18:51 |
| robertmyers | amrith: to back it up? | 18:51 |
| cp16net | or is that handled by the cinder driver | 18:51 |
| denis_makogon | cp16net, i guess yes | 18:51 |
| *** eguz has joined #openstack-trove | 18:51 | |
| vipul | related question.. do cinder snapshots live beyond the volume lifespan? | 18:51 |
| cp16net | and the storage used for cinder | 18:52 |
| SlickNik | vipul: I believe they do. | 18:52 |
| amrith | robertmyers: the draft says it will flush database to disk and place in read only mode | 18:52 |
| amrith | I wonder how we will do this | 18:52 |
| SlickNik | cp16net: It depends on the cinder conf. | 18:52 |
| vgnbkr | Isn't this another "throw out the txn log & user's data, update in place" scheme? | 18:52 |
| robertmyers | amrith: for mysql it is a simple command | 18:52 |
| denis_makogon | vipul, snapshots live as the separate entity, almost independent from the origin volume | 18:52 |
| SlickNik | amrith: I'm curious about that as well. | 18:52 |
| robertmyers | amrith: not sure how all datastores will do it | 18:52 |
| amrith | robertmyers: the command is easy | 18:53 |
| amrith | robertmyers: but with transactions in flight, what happens? | 18:53 |
| denis_makogon | robertmyers, almost the same for mongo/cassandra | 18:53 |
| kevinconway | everyone should use sqlite. it is always flushed to disk | 18:53 |
| robertmyers | amrith: it locks the DB | 18:53 |
| denis_makogon | amcrn, instance would not receive transaction because it's in readonly | 18:53 |
| amrith | robertmyers: in effect, this may not require a reboot but it will cause the client(s) to stall | 18:54 |
| denis_makogon | amrith, lock doesn't requires to stop the DB | 18:54 |
| robertmyers | amrith: no, they can still connect | 18:54 |
| SlickNik | So I like the idea, and see the justification. But I find the BP a bit, how should I say this, sparse on details (especially regarding the r/o consistency pieces). | 18:54 |
| denis_makogon | amrith, for mysql it's the simple querry | 18:54 |
| amrith | denis_makogon: let me ask this differently. Will this be disruptive to client apps? will client apps stall? | 18:54 |
| kevinconway | what if you took pairs of snapshots? one volume on vm | 18:54 |
| *** eghobo has quit IRC | 18:55 | |
| amrith | robertmyers: issue isn't about connect. What about a person with a connection. While a long running txn is in flight, you can't put the db in ro mode. | 18:55 |
| denis_makogon | kevinconway, for cinder they would be two different snapshots | 18:55 |
| denis_makogon | as for trove | 18:55 |
| robertmyers | amrith: this is the same as running percona xtrabackup on a DN | 18:55 |
| robertmyers | DB | 18:55 |
| vipul | amrith: isn't that what you would have to do with mysqldump though? | 18:55 |
| *** khyati has quit IRC | 18:56 | |
| dougshelley66 | what about the question from vgnbkr? | 18:56 |
| dougshelley66 | unless i missed something, it seems relevant given the point in time discussion | 18:56 |
| *** demorris has quit IRC | 18:57 | |
| amrith | robertmyers: it would but not unless you use the --single-transaction option | 18:57 |
| amrith | robertmyers: otherwise it will generate a per-table snapshot | 18:57 |
| denis_makogon | SlickNik, yes, BP misses consistency description but it doesn't causes the any issue to the implemention | 18:57 |
| amrith | if you are taking a snapshot (of the volume) and the restore is not guaranteed to be a consistent database, I'm wondering what the value is | 18:57 |
| robertmyers | amrith: for myisam it flushes the DB with write lock then copies the tables | 18:57 |
| *** sgotliv has quit IRC | 18:58 | |
| robertmyers | that is the same workflow as this | 18:58 |
| amrith | robertmyers: try innodb | 18:58 |
| denis_makogon | SlickNik, we could re-visit the BP one first draft of the implementation will be released | 18:58 |
| amrith | robertmyers: for myisam you could use mysqlhotcopy as well | 18:58 |
| amrith | core: I would like the use-case for this bp to be refined | 18:58 |
| amrith | it is not analogous to mysqldump | 18:58 |
| amrith | because it is a disk volume snapshot | 18:59 |
| robertmyers | amrith: I think it is clear | 18:59 |
| amrith | if you have txn's in flight and you want to lock the db to ro it is disruptive | 18:59 |
| denis_makogon | robertmyers, agreed | 18:59 |
| robertmyers | it will have issues | 18:59 |
| robertmyers | but all backups have problems | 18:59 |
| robertmyers | it is up to the admin to choose the one with the least | 18:59 |
| amrith | robertmyers: the issue is whether the db you restore from this snapshot has consistency guarantees | 18:59 |
| *** demorris has joined #openstack-trove | 18:59 | |
| vipul | robertmyers: Yea i tend to agree. I think deployers that do not have Swift may opt to choose something like this for their strategy | 19:00 |
| robertmyers | amrith: it will be consistent with a lock | 19:00 |
| denis_makogon | vipul, agreed | 19:00 |
| amrith | robertmyers: getting the lock would cause (potentially) several clients to stall | 19:00 |
| denis_makogon | vipul, since in public clouds Swift container space costs alot =) | 19:00 |
| robertmyers | amrith: I don't think so | 19:00 |
| amrith | robertmyers: love to take it up offline | 19:01 |
| grapex | I have an idea I'd like to submit | 19:01 |
| SlickNik | amrith: I agree with you; but users do have flexibility as to when to issue the backup call as well. | 19:01 |
| esmute | grapex: is it in the agenda? | 19:01 |
| grapex | Nope, but the meetings over by now I thought | 19:01 |
| vipul | esmute: lol | 19:01 |
| *** pdmars_ has joined #openstack-trove | 19:01 | |
| esmute | ok.. :P | 19:01 |
| denis_makogon | can we still continue | 19:01 |
| denis_makogon | ? | 19:01 |
| grapex | I think we've spent a lot of these meetings talking about the same blueprints. I think when a bp is pushed back we should move it to the end of the list | 19:01 |
| cp16net | grapex: +1000 | 19:02 |
| cp16net | :) | 19:02 |
| SlickNik | grapex: I like the idea. | 19:02 |
| vipul | grapex: +1.. it seems like we are discussing the same BPs every week.. and running out of time for folks that may actually have a BP that is solid | 19:02 |
| amcrn | +1 | 19:02 |
| amrith | SlickNik: I move to table my BP until SnowDust and I discuss with hub_cap | 19:02 |
| esmute | it seems denis_makogon is the only developer here :P | 19:03 |
| openstackgerrit | Khyati Sheth proposed a change to openstack/trove: Implement Mongodb config groups https://review.openstack.org/85795 | 19:03 |
| SlickNik | amrith: cool, you don't have to bring it up until you're ready. | 19:03 |
| *** yogesh has quit IRC | 19:03 | |
| grapex | Good talk today everyone. Rax has a meeting so talk to you in an hour | 19:03 |
| SnowDust | Thanks all :) | 19:03 |
| SlickNik | grapex / amcrn / vipul: | 19:03 |
| SlickNik | Just to close on the volume snapshot one. | 19:03 |
| denis_makogon | SlickNik, did my last BP got approved ? | 19:03 |
| SlickNik | denis_makogon: Not yet | 19:04 |
| denis_makogon | SlickNik, what's the issue with it ? | 19:04 |
| vipul | I personally think it's a valid option to introduce. Others seem to have some concern | 19:04 |
| *** khyati has joined #openstack-trove | 19:04 | |
| grapex | vipul SlickNik: I was ok with it | 19:04 |
| *** pdmars has quit IRC | 19:05 | |
| SlickNik | Okay, cool. | 19:05 |
| denis_makogon | amcrn, what's your oppinion ? | 19:05 |
| amcrn | for the record, i'd vote to defer because given the churn above, it's absolutely guaranteed that the code review will go through dozens of patch-sets | 19:05 |
| amcrn | because it's not clear some of the details | 19:05 |
| denis_makogon | amcrn, what kind of details ? | 19:06 |
| amcrn | then the reviewers will once again become the bad guys for "inhibiting progress" and "why didn't you tell me this when the bp was approved" | 19:06 |
| *** kevinconway has quit IRC | 19:06 | |
| *** kevinconway_ has joined #openstack-trove | 19:06 | |
| dougshelley66 | amcrn +1 | 19:06 |
| *** yogesh has joined #openstack-trove | 19:06 | |
| *** yogesh has quit IRC | 19:06 | |
| denis_makogon | amcrn, please point me what i have missed in the BP ? | 19:07 |
| vipul | this seems like a godo one for the mailing list. Why don't we get everyone's concerns out there.. and then revist | 19:07 |
| *** yogesh has joined #openstack-trove | 19:08 | |
| esmute | amcrn: +1. Seems like amrith, robertmyers and denis_makogon needs to iron things out offline. | 19:08 |
| amrith | SlickNik: I'm happy to summarize my comments along withthose of Doug and Morgan that scrolled by really quickly and post | 19:08 |
| amrith | let me know where | 19:08 |
| amrith | there are a couple of nits that must be ironed out such as whether the logs are on the same disk (lvm) as the data or not | 19:10 |
| amrith | if they are, it is easier | 19:10 |
| *** doddstack has quit IRC | 19:10 | |
| amrith | if they are not, life sucks | 19:10 |
| amrith | but, it isn't the end of the world | 19:10 |
| amrith | you may just have a corrupt database and no real way of knowing it | 19:10 |
| *** thedodd has joined #openstack-trove | 19:10 | |
| SlickNik | amrith: Can you send out an email to the ML summarizing those couple of key points? | 19:11 |
| amrith | I will draw the attention of those curious about this to http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/ and in particular the sections on "hard to predict downtime" and "Problems with data on multiple volumes" | 19:12 |
| amrith | SlickNik: No worries | 19:12 |
| amrith | happy to do that. | 19:12 |
| SlickNik | We can also discuss it at Wednesday's meeting, if needed. | 19:12 |
| *** kevinconway_ has quit IRC | 19:12 | |
| esmute | Cores, before you guys go. When you get a change, can you quickly review https://blueprints.launchpad.net/trove/+spec/cross-region-backup-availability? We talked about it last week and i made the suggested API change. | 19:13 |
| *** sbfox has quit IRC | 19:16 | |
| *** demorris has quit IRC | 19:18 | |
| amrith | denis_makogon: you there? | 19:19 |
| denis_makogon | yes | 19:19 |
| amrith | quick question for you, got time? | 19:19 |
| *** thedodd has quit IRC | 19:19 | |
| denis_makogon | amrith, yes] | 19:20 |
| amrith | so, your bp https://wiki.openstack.org/wiki/Trove/NetworkManagerInterface which we didn't discuss today | 19:20 |
| *** thedodd has joined #openstack-trove | 19:20 | |
| denis_makogon | amcrn, yes | 19:20 |
| amrith | would it make trove not work with nova networks | 19:20 |
| amrith | but only with neutron | 19:20 |
| amrith | fyi: I'm not amcrn | 19:20 |
| amcrn | amrith: we do look like twins in real life though, so it's understandable the confusion | 19:21 |
| amrith | amcrn is better looking thouhg | 19:21 |
| denis_makogon | amrith, as you can see i said that this refactoring is based upon driver | 19:21 |
| amcrn | amrith: oh stop it you! *blushes* | 19:21 |
| amcrn | lol | 19:21 |
| amrith | (red in face) | 19:21 |
| denis_makogon | amrith, so it will can work with neutron or nova | 19:21 |
| amrith | well, right now it works with neutron and nova. | 19:22 |
| denis_makogon | amrith, depends on which driver would be mentioned in config | 19:22 |
| amrith | after your change it works with nova and neutron | 19:22 |
| denis_makogon | amrith, no | 19:22 |
| amrith | what's different? | 19:22 |
| amrith | oh? | 19:22 |
| *** thedodd has quit IRC | 19:22 | |
| denis_makogon | amrith, trove doesn't work with neutron | 19:22 |
| denis_makogon | amrith, we're only passing nics to nova nothing else | 19:22 |
| *** demorris has joined #openstack-trove | 19:23 | |
| amrith | that's weird, I could've sworn that I saw fixes that said trove works with neutron | 19:23 |
| denis_makogon | amrith, trove doesn't even has neutronclient as the dependecy | 19:23 |
| amrith | so your bp basically implements neutron support? | 19:23 |
| denis_makogon | amrith, no | 19:23 |
| amrith | ok, I was confused. now I'm more confused | 19:24 |
| *** thedodd has joined #openstack-trove | 19:24 | |
| denis_makogon | amrith, it refactrors the code to use driver based network management implementation | 19:24 |
| amrith | you say that trove only works with nova networks, you aren't implementing support for neutron but you are implementing drivers that will allow trove to work with a non-working neutron? | 19:24 |
| denis_makogon | amrith, and also adds the nova-network implementation | 19:24 |
| amrith | so, what's the benefit? at some point when trove works with nova networks or neutron, why do we need this network manager thing? | 19:25 |
| denis_makogon | amrith, nova-network is going to be deprecated | 19:25 |
| amrith | ok | 19:25 |
| denis_makogon | amcrn, we need to switch easity from nova to neutron | 19:26 |
| vipul | So i'll chime in here.. theree may be installations of trove that need to work on older nova-network, and others that require neutron. This driver based model will allow both to co-exist | 19:26 |
| denis_makogon | vipul, correct | 19:26 |
| amrith | so vipul, in the future when neutron is the new shiny thing and customers want to still run trove but (say) on havana | 19:27 |
| amrith | then what happens? | 19:27 |
| amrith | would this feature help me? | 19:27 |
| amrith | or would it get in the way? | 19:27 |
| denis_makogon | amcrn, it would help you to use neutron instead of nova | 19:27 |
| amrith | amcrn: we need to get a picture taken together with captions ;) | 19:28 |
| amrith | denis_makogon: will neutron be supported on havana? | 19:28 |
| denis_makogon | amcrn, you would need to just switch the driver in the conf file and that restart the trove | 19:28 |
| *** amcrn is now known as notamrith | 19:28 | |
| denis_makogon | amrith, i guess yes | 19:28 |
| amrith | amcrn: +1 | 19:28 |
| vipul | amrith: yea i believe this driver model would just end up being a single driver | 19:28 |
| denis_makogon | vipul, yes, when nova-network will gona forever, we would deprecate nova-network driver | 19:29 |
| amrith | vipul: so from trove's perspective, the dependency is on new-driver-to-be-written | 19:29 |
| *** SnowDust has left #openstack-trove | 19:29 | |
| amrith | and new-driver-to-be-written will have dependencies on nova networks and neutron | 19:29 |
| vipul | amrith: and annashen is taking care of imnplementing the neutron driver | 19:29 |
| vipul | well denis_makogon will refactor the code so that a neutron-driver can exist | 19:29 |
| denis_makogon | vipul, correct annashen will do that | 19:29 |
| denis_makogon | vipul, and again, correct | 19:30 |
| vipul | and denis_makogon will submit the 1st impl which allows trove to work as it does today with nova-network | 19:30 |
| amrith | vipul: I'm still not getting a warm fuzzy feeling that in this new world order, trove can continue to be used with havana and grizzly | 19:30 |
| amrith | so if you recall: several folks are looking to stick with nova-networks for a while | 19:30 |
| amrith | and I'm concerned (maybe mistakenly) that this change may break that | 19:30 |
| vipul | amrith: yes, as part of denis_makogon's patch, we need to make sure everything works as it does today | 19:30 |
| vipul | which is with nova-network | 19:31 |
| amrith | OK, thanks. that's what I was hoping. | 19:31 |
| vipul | and for those folks brave enough to run Neutron, annashen will enable that | 19:31 |
| denis_makogon | amrith, vipul, yes, that's why i added to the implementation nova-network driver | 19:31 |
| amrith | OK, thanks for the clarification denis_makogon, vipul. | 19:31 |
| amrith | notamrith: you may rename yourself now ;) | 19:32 |
| *** notamrith is now known as amcrn | 19:32 | |
| vipul | nice amcrn | 19:32 |
| amcrn | :) | 19:32 |
| annashen | vipul, thanks for the highlight | 19:35 |
| amrith | in Atlanta, we'll get a picture taken. and we'll have captions on it. As an aside, I had the Guiness Book of records as a kid and it had a picture of Robert Wadlow, tallest man in the world. The picture in that book was like this one. https://www.flickr.com/photos/nerdboy/10585824844/ ... Caption "Robert is the one wearing glasses" | 19:36 |
| amcrn | amrith: lol | 19:36 |
| *** Barker has joined #openstack-trove | 19:39 | |
| *** grapex has quit IRC | 19:44 | |
| *** michael-yu has quit IRC | 19:44 | |
| *** grapex has joined #openstack-trove | 19:44 | |
| *** ViswaV has quit IRC | 19:49 | |
| *** michael-yu has joined #openstack-trove | 19:51 | |
| *** grapex has quit IRC | 19:53 | |
| *** michael-yu has left #openstack-trove | 19:59 | |
| *** grapex has joined #openstack-trove | 20:01 | |
| *** yogesh has quit IRC | 20:01 | |
| *** yogesh has joined #openstack-trove | 20:04 | |
| *** ViswaV has joined #openstack-trove | 20:23 | |
| *** robertmyers has quit IRC | 20:23 | |
| *** robertmyers has joined #openstack-trove | 20:24 | |
| *** mattgriffin has quit IRC | 20:25 | |
| *** mattgriffin has joined #openstack-trove | 20:26 | |
| *** sbfox has joined #openstack-trove | 20:26 | |
| *** kevinconway has joined #openstack-trove | 20:28 | |
| openstackgerrit | Kaleb Pomeroy proposed a change to openstack/trove: Adds the foundation for datastore capabilities https://review.openstack.org/83503 | 20:37 |
| *** Barker has quit IRC | 20:39 | |
| *** michael-yu has joined #openstack-trove | 20:58 | |
| imsplitbit | core + anyone interested https://review.openstack.org/#/c/82123/ https://review.openstack.org/#/c/82124/ | 21:08 |
| *** sriram_ has joined #openstack-trove | 21:09 | |
| *** sriram_tesora has quit IRC | 21:12 | |
| imsplitbit | when manually installing the client changes for metadata into the trove tox environments all tests pass | 21:14 |
| denis_makogon | imsplitbit, ping | 21:27 |
| denis_makogon | imsplitbit, question, https://review.openstack.org/#/c/82123/8/trove/db/sqlalchemy/migrate_repo/versions/026_add_instance_metadata.py - should constraint be named same as foreign column, instance_id instead of the instance_uuid ? | 21:28 |
| *** esp1 has joined #openstack-trove | 21:32 | |
| *** esp1 has left #openstack-trove | 21:32 | |
| *** grapex has quit IRC | 21:37 | |
| imsplitbit | I suppose it's a matter of discussion | 21:39 |
| imsplitbit | I don't think that has any real relavence to the app. is it a change that matters? | 21:40 |
| denis_makogon | imsplitbit, that's why i ask | 21:41 |
| denis_makogon | imsplitbit, each model has the same name for the column | 21:41 |
| denis_makogon | backup model | 21:41 |
| denis_makogon | backup contains foreign key of the instance id, column that stores the foreign key has the same name | 21:42 |
| denis_makogon | imsplitbit, lets keep thing pretty standard | 21:43 |
| imsplitbit | ok are you asking me to change the field name instance_uuid or change the name of the foreign key to to something else? | 21:43 |
| denis_makogon | imsplitbit, change name of the column | 21:44 |
| denis_makogon | instance_uuid -> instance_id | 21:44 |
| imsplitbit | anyone else care to weigh in on this? | 21:44 |
| imsplitbit | I'm fine to go through the change if this is a concensus | 21:44 |
| denis_makogon | imsplitbit, it'll be great | 21:45 |
| imsplitbit | shouldn't take long I'd just hate to make grapex go back and +2 this again | 21:45 |
| amrith | imsplitbit: I can't imagine why anyone would object | 21:45 |
| denis_makogon | from the developer perspective, i have several models that somehow associated with the instance by its id | 21:46 |
| amrith | consistency is a good thing ;) | 21:46 |
| imsplitbit | I don't disagree | 21:46 |
| amrith | ;) | 21:46 |
| denis_makogon | imsplitbit, i know, just thinking out loud | 21:46 |
| imsplitbit | I tend to err on the side of explicitness | 21:46 |
| *** achampion has quit IRC | 21:46 | |
| imsplitbit | the id is a uuid so I called it that | 21:46 |
| denis_makogon | imsplitbit, yeah, totally true | 21:47 |
| imsplitbit | but again, not opposed to changing that | 21:47 |
| denis_makogon | imsplitbit, thanks | 21:47 |
| denis_makogon | imsplitbit, you did great job | 21:48 |
| denis_makogon | imsplitbit, the last question | 21:48 |
| imsplitbit | thanks | 21:48 |
| denis_makogon | imsplitbit, Metadata class | 21:48 |
| denis_makogon | i think it should be inherited from the dict class | 21:48 |
| imsplitbit | what would be the point? | 21:48 |
| imsplitbit | it would override almost everything | 21:48 |
| denis_makogon | it would easier to understand that this type of the class really acts like a dict | 21:49 |
| denis_makogon | suppose we have newbie Py dev | 21:49 |
| denis_makogon | he doesn't know much about buil-ints | 21:49 |
| robertmyers | denis_makogon: subclassing dict is not a good thing | 21:50 |
| denis_makogon | *buit-ins | 21:50 |
| denis_makogon | robertmyers, why ? | 21:50 |
| robertmyers | cause it is a builtin | 21:50 |
| imsplitbit | plus I feel like it's disingenuous to do that because what dict methods if any it *doesn't* implement would fail miserably | 21:50 |
| imsplitbit | I feel like docstrings that indicate that it works like a dict should suffice | 21:51 |
| denis_makogon | imsplitbit, if it works for all, then i'm fine, so as you =) | 21:52 |
| denis_makogon | imsplitbit, so, the only concern is the column name, and nothing else | 21:53 |
| denis_makogon | cu tomorrow, guys, have a great day | 21:53 |
| * denis_makogon gone | 21:53 | |
| *** demorris has quit IRC | 21:59 | |
| *** amcrn has quit IRC | 22:04 | |
| *** robertmyers has quit IRC | 22:07 | |
| *** amytron has quit IRC | 22:21 | |
| *** sriram_ has quit IRC | 22:22 | |
| openstackgerrit | Anna Shen proposed a change to openstack/trove: Add integration test for Neutron support https://review.openstack.org/82673 | 22:23 |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Make storage strategy available for trove API and TM https://review.openstack.org/86242 | 22:25 |
| *** NehaV has quit IRC | 22:25 | |
| *** denis_makogon has quit IRC | 22:27 | |
| *** yogesh has quit IRC | 22:36 | |
| *** achampion has joined #openstack-trove | 22:58 | |
| *** mattgriffin has quit IRC | 23:01 | |
| *** doddstack has joined #openstack-trove | 23:03 | |
| *** thedodd has quit IRC | 23:04 | |
| *** achampio1 has joined #openstack-trove | 23:05 | |
| *** achampion has quit IRC | 23:08 | |
| *** doddstack has quit IRC | 23:08 | |
| *** Barker has joined #openstack-trove | 23:17 | |
| openstackgerrit | Nikhil Manchanda proposed a change to openstack/trove: Updated from global requirements https://review.openstack.org/85844 | 23:22 |
| *** flaper87 is now known as flaper87|afk | 23:23 | |
| *** pdmars_ has quit IRC | 23:26 | |
| *** mattgriffin has joined #openstack-trove | 23:36 | |
| *** yidclare has quit IRC | 23:39 | |
| *** jcru has quit IRC | 23:42 | |
| *** arborism has joined #openstack-trove | 23:49 | |
| *** michael-yu has quit IRC | 23:53 | |
| *** kevinconway has quit IRC | 23:55 | |
| *** arborism is now known as amcrn | 23:58 | |
| *** michael-yu has joined #openstack-trove | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!