*** ChanServ changes topic to "Restarting gerrit really quick to fix replication issue" | 00:00 | |
*** pdmars has quit IRC | 00:00 | |
*** ChanServ changes topic to "Trove Openstack Database as a Service | Docs https://github.com/openstack/trove | Channel Logs http://eavesdrop.openstack.org/irclogs/ | IRC must read http://sackheads.org/~bnaylor/spew/away_msgs.html" | 00:02 | |
*** demorris has quit IRC | 00:10 | |
*** achampion has joined #openstack-trove | 00:10 | |
*** NehaV has joined #openstack-trove | 00:13 | |
*** saurabhs has left #openstack-trove | 00:14 | |
*** yidclare has quit IRC | 00:16 | |
*** Barker has joined #openstack-trove | 00:20 | |
*** NehaV has quit IRC | 00:22 | |
*** matsuhashi has joined #openstack-trove | 00:30 | |
*** eguz has quit IRC | 00:45 | |
*** ViswaV_ has quit IRC | 01:07 | |
*** Barker has quit IRC | 01:09 | |
*** michael-yu has quit IRC | 01:09 | |
*** rueb7363 has joined #openstack-trove | 01:20 | |
*** amcrn has quit IRC | 01:39 | |
*** matsuhashi has quit IRC | 01:40 | |
*** haomaiw__ has quit IRC | 01:42 | |
*** matsuhas_ has joined #openstack-trove | 01:43 | |
*** haomaiwang has joined #openstack-trove | 01:43 | |
*** haomaiw__ has joined #openstack-trove | 02:02 | |
*** haomaiwang has quit IRC | 02:05 | |
*** rueb7363 has quit IRC | 02:28 | |
*** rueb7363 has joined #openstack-trove | 02:28 | |
*** coolsvap|afk is now known as coolsvap | 02:35 | |
*** harlowja is now known as harlowja_away | 02:35 | |
*** ViswaV has joined #openstack-trove | 02:38 | |
*** ViswaV_ has joined #openstack-trove | 02:39 | |
*** ViswaV has quit IRC | 02:42 | |
*** matsuhas_ has quit IRC | 02:49 | |
*** matsuhashi has joined #openstack-trove | 02:49 | |
*** matsuhas_ has joined #openstack-trove | 02:52 | |
*** matsuhashi has quit IRC | 02:52 | |
*** matsuhas_ has quit IRC | 02:58 | |
*** demorris has joined #openstack-trove | 03:05 | |
*** NehaV has joined #openstack-trove | 03:28 | |
*** demorris has quit IRC | 03:34 | |
*** nosnos has quit IRC | 03:35 | |
*** rueb7363 has quit IRC | 03:43 | |
*** shivam has quit IRC | 03:44 | |
*** rueb7363 has joined #openstack-trove | 03:48 | |
*** NehaV has quit IRC | 04:08 | |
*** ViswaV_ has quit IRC | 04:22 | |
*** sbfox has joined #openstack-trove | 04:23 | |
*** nosnos has joined #openstack-trove | 04:25 | |
*** saju_m has joined #openstack-trove | 04:27 | |
*** saju_m has quit IRC | 04:27 | |
*** coolsvap is now known as coolsvap|afk | 04:35 | |
*** sbfox has quit IRC | 04:41 | |
*** achampio1 has joined #openstack-trove | 04:42 | |
*** achampion has quit IRC | 04:44 | |
*** achampion has joined #openstack-trove | 04:47 | |
*** rueb7363 has quit IRC | 04:48 | |
*** achampio1 has quit IRC | 04:48 | |
*** coolsvap|afk is now known as coolsvap | 04:52 | |
*** denis_makogon has joined #openstack-trove | 06:09 | |
openstackgerrit | Anna Shen proposed a change to openstack/trove-integration: Add neutron switch for ini tests https://review.openstack.org/87856 | 06:14 |
---|---|---|
*** flaper87|afk is now known as flaper87 | 07:04 | |
*** iartarisi has joined #openstack-trove | 07:19 | |
*** denis_makogon has quit IRC | 08:25 | |
*** sbfox has joined #openstack-trove | 08:44 | |
*** eghobo has joined #openstack-trove | 08:51 | |
*** SushillKM has joined #openstack-trove | 08:51 | |
*** SushillKM has left #openstack-trove | 09:11 | |
*** fifieldt has joined #openstack-trove | 09:12 | |
fifieldt | hi all | 09:12 |
*** SnowDust has joined #openstack-trove | 09:18 | |
*** nosnos has quit IRC | 10:07 | |
*** nosnos has joined #openstack-trove | 10:12 | |
*** dmakogon_ is now known as denis_makogon | 10:14 | |
denis_makogon | fifieldt, hi | 10:14 |
fifieldt | hi :) | 10:16 |
*** demorris has joined #openstack-trove | 10:16 | |
*** eghobo has quit IRC | 10:21 | |
*** SnowDust has quit IRC | 10:22 | |
denis_makogon | fifieldt, what's up? | 10:22 |
fifieldt | many things :) | 10:22 |
fifieldt | I've put in about 9 hours of work today so far on testing trove and fixing docs and packaging | 10:23 |
fifieldt | one thing that would be really awesome, is if you have a nice, easy guide to create the images that trove uses | 10:23 |
denis_makogon | fifieldt, of course, images from Trove is the real bottleneck at this time | 10:31 |
fifieldt | I don't need images | 10:31 |
fifieldt | just instructions on how to create them | 10:31 |
fifieldt | :) | 10:31 |
*** sbfox has quit IRC | 10:32 | |
denis_makogon | fifieldt, that's what i'm talking about, now we don't have any pure standard way to create images outside the integration or devstack | 10:32 |
fifieldt | I don't even need a standard way :) | 10:32 |
fifieldt | just a way | 10:32 |
fifieldt | without any method at all, trove is unusable for real people :) | 10:33 |
*** sbfox has joined #openstack-trove | 10:33 | |
denis_makogon | fifieldt, agreed | 10:33 |
denis_makogon | fifieldt, but we could say, use cloudinit to deploy the agent to vanilla image | 10:34 |
fifieldt | is that method written down somewhere? | 10:34 |
*** nosnos has quit IRC | 10:34 | |
*** nosnos has joined #openstack-trove | 10:35 | |
*** SnowDust has joined #openstack-trove | 10:35 | |
*** nosnos has quit IRC | 10:39 | |
*** iartarisi has left #openstack-trove | 10:48 | |
*** demorris has quit IRC | 10:48 | |
fifieldt | denis_makogon ? | 10:57 |
*** nosnos has joined #openstack-trove | 11:06 | |
amrith | fifieldt: yes, these procedures are written down. I know that a couple of people have discussed it in the recent past. I'll find a link for you. | 11:08 |
fifieldt | great, that would be excellent | 11:08 |
*** coolsvap is now known as coolsvap|afk | 11:15 | |
denis_makogon | fifieldt, cloudinit mechanis is not described in any docs, i suppose | 11:18 |
fifieldt | thanks for the confirmation denis_makogon | 11:19 |
fifieldt | this is, I believe, precisely the problem we need to solve | 11:19 |
denis_makogon | poor doc coverage is the huge issue | 11:19 |
fifieldt | check it out, denis_makogon: http://docs-draft.openstack.org/35/87135/12/check/gate-openstack-manuals-tox-doc-publish-checkbuild/1c497b4/publish-docs/trunk/install-guide/install/apt/content/trove-install.html :) | 11:20 |
fifieldt | if we can get the image stuff down | 11:21 |
fifieldt | that's the major thing | 11:21 |
amrith | fifieldt ... I was going to ping you about something else as well, got a second? | 11:24 |
*** ashestakov has joined #openstack-trove | 11:24 | |
fifieldt | if you can put up with me being slow and tired, sure :D | 11:24 |
amrith | ok, let's try | 11:24 |
amrith | about https://review.openstack.org/#/c/87135/ | 11:24 |
amrith | I'm curious what the 'openstack way' is. | 11:25 |
amrith | But, it seems like Laurel was working her way through review you comments (some from you) | 11:25 |
amrith | and now you are submiting patch sets over hers | 11:26 |
amrith | not sure what the intent is | 11:26 |
amrith | should she continue to work on it | 11:26 |
amrith | or are you now in charge? | 11:26 |
fifieldt | to be honest - this extent of change is abnormal | 11:26 |
amrith | I wasn't asking about the amount of change | 11:26 |
fifieldt | I decided to do it because I figured Laurel was asleep | 11:26 |
fifieldt | and because we need this quite urgently | 11:27 |
amrith | I was asking about the process of submitting patches in someone elses bug fix | 11:27 |
fifieldt | in a normal case | 11:27 |
fifieldt | (just talking about docs here) you can get people submitting fixes to someone else's patch | 11:27 |
amrith | it would be more polite to let her know, maybe? how'd you like the same thing done to you? | 11:27 |
fifieldt | but only for minor thing | 11:27 |
fifieldt | amrith, I did send her an email | 11:27 |
amrith | OK, just curious what the openstack way was. I suspect informing someone that you are going to submit patch sets on their bug fix is the norm; I'd have expected that waiting for a reply would be respectful but I guess I was wrong | 11:28 |
amrith | thanks for the clarification | 11:28 |
fifieldt | amrith, this is a little bit of a special case | 11:28 |
amrith | we're all special cases ;) | 11:29 |
fifieldt | no, I really do hope Laurel is feeling OK | 11:29 |
fifieldt | I'm happy to jump on the phone if needed | 11:29 |
fifieldt | her work was a fantastic basis | 11:29 |
amrith | I'll let you sort that out with her. maybe jumping on the phone first would be a better way to do things in the future; just saying | 11:29 |
fifieldt | amrith, though, as above, due to timezones - that would not have been possible in this case | 11:30 |
amrith | well, you don't reward a person for 'fantastic work' this way (at least not where I come from) | 11:30 |
fifieldt | amrith, she is still receiving author credit for the patch | 11:30 |
amrith | I was going to ask her about documentation on making images (which she has). I think I'll hold off on that. As for "credit", just remember, not all of us do this stuff for "credit". | 11:30 |
fifieldt | I'm in this for fun too, amrith :) | 11:31 |
amrith | what about Laurel, you think this is fun for her? | 11:32 |
amrith | I'll let you explain it to her, I'm done. And if you want image documentation, you can ask her for it. | 11:32 |
amrith | take care | 11:32 |
fifieldt | thanks, amrith | 11:32 |
fifieldt | I hope your day improves from this beginning | 11:32 |
fifieldt | sorry again for the ruffled feathers | 11:32 |
amrith | I tend to have a live frog for breakfast each day, that way it only gets better. Today I don't need the live frog breakfast. | 11:33 |
fifieldt | nice :D | 11:33 |
amrith | fifieldt: by the way, not my feathers. I'm bald. | 11:38 |
amrith | denis_makogon: you there? | 11:39 |
amrith | denis_makogon: sent you email with a q; thx | 11:41 |
denis_makogon | amrith, saw your email | 11:42 |
denis_makogon | amrith, most of the questions are appear because of lack knowledge about trove, i guess | 11:43 |
denis_makogon | amrith, (a) In particular, it would be good to understand exactly what the limitations of the proposed implementation are likely to be. This could include things like configurations that would work, storage engines that would be supported (or not), performance considerations, etc., | 11:43 |
denis_makogon | that's your first question, it's fully covered with the wiki page | 11:44 |
amrith | denis_makogon: i don't follow. email was about neutron bug that is breaking my build ;) | 11:44 |
denis_makogon | amrith, ah, about that | 11:44 |
amrith | you are talking about different email ... | 11:44 |
amrith | about the email you are refering to, maybe worth putting on agenda for today's meeting. | 11:44 |
denis_makogon | amrith, puting such things to agenda will blow meeting out | 11:45 |
denis_makogon | amrith, we should deal with it, out of the meetings | 11:45 |
amrith | how's the best way to address? | 11:45 |
amrith | works for me | 11:45 |
amrith | not right now though, I have to get in a car and spend 45 minutes with a bunch of people who are texting, eating or doing make-up (while driving) | 11:46 |
amrith | want to pick a time? could do irc if that's what you had in mind | 11:46 |
denis_makogon | neutron problem is not our problem | 11:46 |
denis_makogon | it'll be fixed asap | 11:46 |
amrith | well, it is mine ... I have had about 51 tries at getting it past zuul | 11:47 |
amrith | personally, I think it is a conspiracy | 11:47 |
amrith | ;) | 11:47 |
denis_makogon | amrith, i read thread at bug report, so it looks like it should be fixed soon | 11:48 |
amrith | would IRC in maybe 1 hour or 75min work for you? | 11:48 |
*** sbfox1 has joined #openstack-trove | 11:48 | |
amrith | denis, my concern is that I'm not sure I know which bug it is ... seems like it isn't (exactly) one of the bugs reported/attributed. | 11:48 |
*** sbfox has quit IRC | 11:48 | |
amrith | but something nearby | 11:48 |
amrith | but you are right, I hope it gets fixed soon | 11:49 |
amrith | anyway, re: blueprint for snapshot, want to pick a time? either we could do later this morning (in about an hour or 1:15)? | 11:49 |
amrith | I'm going to sign off now, if you would please send me an email as anything you say me be lost in the irc traffic and my bouncer isn't quite doing scrollback correctly. will talk later. | 11:50 |
denis_makogon | amrith, yes, lets talk later | 11:58 |
*** nosnos has quit IRC | 12:17 | |
*** achampion has quit IRC | 12:23 | |
*** sbfox1 has quit IRC | 12:27 | |
SnowDust | denis_makogon, saw ur comments on https://review.openstack.org/70322 | 12:29 |
SnowDust | makes sense .. i will do this today | 12:30 |
SnowDust | suppose someone not doing it ;) | 12:30 |
denis_makogon | SnowDust, i guess no | 12:30 |
SnowDust | yes ..so i will do this as a patchset update | 12:30 |
denis_makogon | i think OpenStack infra needs to do this automatically | 12:31 |
denis_makogon | the gate job should look like the "requirements" job | 12:31 |
*** pdmars has joined #openstack-trove | 12:52 | |
*** sbfox has joined #openstack-trove | 12:53 | |
*** Barker has joined #openstack-trove | 12:57 | |
*** pdmars has quit IRC | 12:58 | |
*** demorris has joined #openstack-trove | 12:59 | |
*** chipc has quit IRC | 13:01 | |
*** chipc has joined #openstack-trove | 13:01 | |
*** pdmars has joined #openstack-trove | 13:03 | |
*** jcru has joined #openstack-trove | 13:07 | |
fifieldt | this make sense to anyone ... https://bugs.launchpad.net/trove/+bug/1308529 ? | 13:09 |
*** sbfox has quit IRC | 13:11 | |
*** SnowDust has quit IRC | 13:13 | |
*** achampion has joined #openstack-trove | 13:16 | |
openstackgerrit | A change was merged to openstack/trove: Correct the command to stop cassandra server https://review.openstack.org/82080 | 13:17 |
*** NehaV has joined #openstack-trove | 13:17 | |
*** NehaV has quit IRC | 13:29 | |
*** mattgrif_ has joined #openstack-trove | 13:34 | |
*** NehaV has joined #openstack-trove | 13:38 | |
openstackgerrit | Daniel Salinas proposed a change to openstack/trove: Implement topology api https://review.openstack.org/87970 | 13:48 |
*** ViswaV has joined #openstack-trove | 13:50 | |
*** ViswaV_ has joined #openstack-trove | 13:51 | |
*** robertmyers has joined #openstack-trove | 13:51 | |
amrith | denis_makogon: yt? sorry I was stuck in traffic. also thanks for kicking 82080 free. | 13:51 |
*** casanch1 has joined #openstack-trove | 13:52 | |
*** sbfox has joined #openstack-trove | 13:53 | |
*** ViswaV has quit IRC | 13:55 | |
casanch1 | hi, is it possible to install a single instance of trove with api, taskmanager and guestagent in devstack? | 13:55 |
casanch1 | I'm following this: https://wiki.openstack.org/wiki/Trove/installation, but it fails because it cannot find enable_service, which I found are: tr-api, tr-tmgr but I cannot find the one for guestagent | 13:56 |
denis_makogon | casanch1, you are able to install trove with devstack, but, unfortunately, you are not able to create instance through trove | 13:57 |
denis_makogon | casanch1, take a look at https://github.com/openstack/trove-integration | 13:57 |
*** mattgrif_ has quit IRC | 13:58 | |
denis_makogon | amrith, cassandra patch landed | 13:58 |
amrith | denis_makogon: yes, thanks. it needed your magic touch | 13:58 |
denis_makogon | amrith, yeah, of course =)) | 13:58 |
denis_makogon | amrith, now we can discuss your previous email | 13:58 |
denis_makogon | amrith, can we ? | 13:58 |
amrith | just got into office and have a meeting in 1 minutes | 13:59 |
amrith | 1 minute | 13:59 |
amrith | what time is it for you now? | 13:59 |
denis_makogon | 5 PM | 14:00 |
amrith | here's waht the rest of my day looks like | 14:00 |
amrith | i have this and another meeting till about 1pm (which is 3 hours from now) | 14:01 |
amrith | we have the trove meeting at 2pm | 14:01 |
*** sbfox has quit IRC | 14:01 | |
amrith | could we meet between 1pm and 2pm? that would be between 8pm and 9pm your time? | 14:01 |
denis_makogon | yes, we can | 14:02 |
denis_makogon | ping me | 14:02 |
amrith | wilco, thx denis | 14:02 |
denis_makogon | when you'll be ready | 14:02 |
denis_makogon | amrith, thx to you too | 14:02 |
openstackgerrit | Daniel Salinas proposed a change to openstack/trove: Add instance metadata functionality to trove https://review.openstack.org/82123 | 14:16 |
*** NehaV has quit IRC | 14:18 | |
*** fifieldt has quit IRC | 14:24 | |
*** ViswaV_ has quit IRC | 14:24 | |
*** kevinconway has joined #openstack-trove | 14:26 | |
*** NehaV has joined #openstack-trove | 14:37 | |
*** thedodd has joined #openstack-trove | 14:50 | |
*** jmontemayor has joined #openstack-trove | 14:50 | |
*** coolsvap|afk is now known as coolsvap | 14:51 | |
*** sbfox has joined #openstack-trove | 15:17 | |
*** shivamshukla has joined #openstack-trove | 15:48 | |
*** NehaV has quit IRC | 15:50 | |
*** NehaV has joined #openstack-trove | 15:50 | |
*** grapex has joined #openstack-trove | 15:58 | |
*** eghobo has joined #openstack-trove | 16:03 | |
*** jmontemayor has quit IRC | 16:05 | |
*** Barker has quit IRC | 16:06 | |
*** grapex has quit IRC | 16:06 | |
*** Barker has joined #openstack-trove | 16:06 | |
*** grapex has joined #openstack-trove | 16:07 | |
*** shivamshukla has quit IRC | 16:11 | |
*** demorris has quit IRC | 16:13 | |
*** hub_cap has quit IRC | 16:15 | |
*** jmontemayor has joined #openstack-trove | 16:18 | |
*** hub_cap has joined #openstack-trove | 16:18 | |
*** cp16net has quit IRC | 16:32 | |
*** sbfox has quit IRC | 16:32 | |
*** sbfox has joined #openstack-trove | 16:32 | |
*** demorris has joined #openstack-trove | 16:33 | |
*** shivam has joined #openstack-trove | 16:36 | |
*** cp16net has joined #openstack-trove | 16:45 | |
*** cp16net has quit IRC | 16:50 | |
*** cp16net has joined #openstack-trove | 16:51 | |
*** harlowja_away is now known as harlowja | 16:51 | |
*** cp16net has quit IRC | 16:54 | |
*** cp16net has joined #openstack-trove | 16:54 | |
*** cp16net has quit IRC | 16:54 | |
*** cp16net has joined #openstack-trove | 16:55 | |
amrith | denis_makogon: I'm back | 16:57 |
*** amcrn has joined #openstack-trove | 16:57 | |
*** zuqiang has joined #openstack-trove | 17:00 | |
*** amcrn has quit IRC | 17:10 | |
*** eghobo has quit IRC | 17:11 | |
*** eghobo has joined #openstack-trove | 17:11 | |
*** denis_makogon_ has joined #openstack-trove | 17:12 | |
*** denis_makogon has quit IRC | 17:13 | |
*** denis_makogon_ is now known as denis_makogon | 17:13 | |
denis_makogon | amrith, i'm in | 17:13 |
*** dmakogon_ has joined #openstack-trove | 17:13 | |
*** demorris has quit IRC | 17:14 | |
*** ViswaV has joined #openstack-trove | 17:17 | |
*** ViswaV_ has joined #openstack-trove | 17:19 | |
amrith | Hi denis | 17:20 |
amrith | anytime you are ready, let's start | 17:20 |
denis_makogon | 5 mins | 17:21 |
amrith | np. take ur time | 17:21 |
denis_makogon | lets start | 17:22 |
*** ViswaV has quit IRC | 17:22 | |
denis_makogon | let me find your email | 17:22 |
denis_makogon | lets go through all your questions | 17:22 |
denis_makogon | amrith, can we ? | 17:23 |
amrith | sure | 17:23 |
denis_makogon | we have 30m before the meeting | 17:23 |
amrith | let me find the email | 17:23 |
*** michael-yu has joined #openstack-trove | 17:23 | |
amrith | got it | 17:23 |
denis_makogon | could you post your questions and i'll try to answer them | 17:24 |
denis_makogon | i'd like to deal with it once and forever | 17:24 |
amrith | I can't guarantee that but I'll give it a shot | 17:24 |
denis_makogon | lets go | 17:24 |
denis_makogon | the question A | 17:25 |
amrith | first, what are the limitations of this approach, what configurations work, don't work. what storage engines, etc | 17:25 |
amrith | so at a high level | 17:25 |
amrith | does a trove instance necessarily have only one cinder volume | 17:26 |
amrith | does that cinder volume have LVM? | 17:26 |
amrith | or some such thing that will support snapshot capability | 17:26 |
denis_makogon | amrith, yes cinder has lvm, but it's optional | 17:26 |
amrith | will it be required for trove | 17:26 |
amrith | will it be required for this implementation of snapshot | 17:27 |
denis_makogon | limitations: if instance has no cinder volume (ephemeral) - snapshot strategy is not applicapable | 17:27 |
amrith | so that is a limitation that should be listed/documented | 17:27 |
amrith | and maybe the code should check or maybe it will make a snapshot call and get an error | 17:27 |
denis_makogon | of course | 17:28 |
amrith | also if instance has a cinder volume without lvm (if that's possible) it won't work, I assume | 17:28 |
openstackgerrit | Ramashri Umale proposed a change to openstack/trove: Fix prepare call for redis guest agent https://review.openstack.org/84863 | 17:28 |
denis_makogon | lets first talk about Trove and then about CInder and LVM | 17:28 |
amrith | ok | 17:28 |
amrith | let's talk about trove | 17:29 |
amrith | will trove store data only on a cinder volume? | 17:29 |
denis_makogon | amrith, yes | 17:29 |
amrith | or ephimeral? | 17:29 |
denis_makogon | amrith, because volume is mounted directly to database storage directory | 17:29 |
amrith | ephemeral | 17:30 |
amrith | [sp] | 17:30 |
denis_makogon | amrith, if ephemeral is used flow will fail | 17:31 |
amrith | what do you mean by "flow will fail". | 17:31 |
denis_makogon | backup will be marked as FAILED | 17:31 |
amrith | ok, in other words one limitation is that the trove instance must have data stored on a cinder volume. | 17:32 |
denis_makogon | yes | 17:32 |
amrith | can a trove instance have >1 data volume | 17:32 |
denis_makogon | no | 17:32 |
amrith | now or forever? | 17:32 |
denis_makogon | you cannot mount more that one remote storage into the one mount point | 17:32 |
denis_makogon | amrith, forever | 17:33 |
*** SnowDust has joined #openstack-trove | 17:33 | |
amrith | that's interesting | 17:33 |
denis_makogon | amrith, databases stores its data in one place | 17:33 |
SnowDust | hi all | 17:33 |
denis_makogon | in general | 17:33 |
amrith | odd, I use MySQL instances with data in one place and logs in another | 17:33 |
denis_makogon | amrith, we're talking only about data | 17:34 |
denis_makogon | amrith, backup is the stream of the data and only | 17:34 |
amrith | so, let me try this again | 17:35 |
amrith | let's say we talk mysql only, and innodb only | 17:35 |
denis_makogon | yes | 17:35 |
amrith | innodb stores its data in datadir | 17:35 |
denis_makogon | yes | 17:35 |
amrith | it also stores a redolog | 17:35 |
denis_makogon | volume gets mounted into the datadir | 17:35 |
denis_makogon | amrith, yes | 17:35 |
*** yogesh has joined #openstack-trove | 17:36 | |
denis_makogon | amrith, Trove doesn't work with redo logs or bin logs, yet | 17:36 |
*** yidclare has joined #openstack-trove | 17:36 | |
amrith | you are beginning to scare me, a little | 17:36 |
amrith | but go on | 17:37 |
denis_makogon | amrith, why am i scaring you ? | 17:37 |
amrith | what are the default values of datadir and innodb_data_home_dir in trove | 17:37 |
denis_makogon | /var/lib/mysql | 17:37 |
amrith | are we requiring that innodb_data_home_dir be null (or not set) | 17:37 |
amrith | so ibdata will go into /var/lib/mysql? | 17:38 |
denis_makogon | sorry, i'm not so familiar with mysql | 17:39 |
amrith | ok, so let's pick a data store that will be implemented in your initial iteration | 17:39 |
denis_makogon | according to actual code, we're relaying that DB data is stored at datadir | 17:39 |
amrith | i see | 17:39 |
denis_makogon | ok, if that will be easier for us, then lets pick cassandra | 17:40 |
amrith | so is innodb_file_per_table set by default in mysql? | 17:40 |
denis_makogon | yes | 17:40 |
denis_makogon | amrith, https://github.com/openstack/trove/blob/master/trove/templates/mysql/config.template | 17:40 |
amrith | so one thing I'm not sure is this ... | 17:41 |
denis_makogon | amrith, that's what mysql uses as the base config | 17:41 |
amrith | the config file you sent me | 17:41 |
amrith | is that something that a user of trove can change? | 17:41 |
amrith | or are they not allowed to change that | 17:41 |
amrith | like, can an operator change that? | 17:41 |
denis_makogon | yes, we're allowing to change it | 17:42 |
denis_makogon | i think we should drop that ability to change it, because we're already have configuration groups, thanks to cp16net | 17:42 |
amrith | well, in some manner, a user has the ability to change it | 17:43 |
denis_makogon | amrith, user has an ability to substitute whole config | 17:43 |
denis_makogon | and of course he could change the datadir, and data will go other place | 17:43 |
*** shivamshukla has joined #openstack-trove | 17:44 | |
*** amcrn has joined #openstack-trove | 17:44 | |
amrith | one second | 17:45 |
amrith | what do we do about shutdown, let me look at your template | 17:45 |
denis_makogon | all supported databases allows to minimize the downtime by setting the read-only option | 17:47 |
amrith | ok | 17:47 |
amrith | and how would you do that in mysql? | 17:47 |
amrith | or cassandra | 17:48 |
amrith | or whatever datastores you will implement in v1 of this process | 17:48 |
denis_makogon | flush tables to FS, set read-only, perform snapshoting, take of the read-only | 17:48 |
*** demorris has joined #openstack-trove | 17:48 | |
amrith | yes, I got that | 17:48 |
amrith | how do you force a mysql database to go readonly | 17:48 |
denis_makogon | sql query | 17:49 |
amrith | in some instances that can take a long time | 17:49 |
amrith | it could take forever if you aren't lucky | 17:49 |
amrith | on the irc on monday I posted some links to people who explain the complexities of snapshot backup for mysql | 17:49 |
denis_makogon | i guess it's the problem of the database itself | 17:49 |
amrith | i see | 17:50 |
denis_makogon | innobackupex and mysql dump does almost the same | 17:50 |
denis_makogon | except block storage snapshotin | 17:50 |
amrith | so, mysqldump will do the database readonly ONLY if you specify --single-transaction | 17:51 |
denis_makogon | of course | 17:51 |
amrith | that's kind of the whole point | 17:51 |
amrith | marking a table read only is different from marking a whole database readonly | 17:51 |
denis_makogon | amcrn, trove allows to pass additional parameters to the main cmd that delivers a backup | 17:51 |
denis_makogon | amcrn, we're not backuping only one table | 17:52 |
amcrn | denis_makogon: for the love of pete, please type a 3rd character before auto-completing | 17:52 |
denis_makogon | amcrn, sorry, =))) | 17:52 |
*** michael-yu has quit IRC | 17:52 | |
SnowDust | Peter ;) | 17:52 |
*** thedodd has quit IRC | 17:53 | |
*** michael-yu has joined #openstack-trove | 17:53 | |
denis_makogon | amrith, we're cannot relay at database at all | 17:54 |
*** _shalkh has joined #openstack-trove | 17:54 | |
*** amrith is now known as notamrcn | 17:54 | |
notamrcn | so | 17:55 |
notamrcn | since we're not backing up only one table | 17:55 |
notamrcn | and you want to lock a whole database | 17:55 |
notamrcn | I'm concerned that the things you have to do are very different, depending on the kind(s) of storage engines in use | 17:55 |
notamrcn | while it is mysql (or percona server, or mariadb or whatever) | 17:56 |
notamrcn | flush tables with read lock has very different semantics depending on whether there's innodb under the covers or myisam | 17:56 |
notamrcn | i'm trying to understand whether this approach of snapshot replication with this 3 step process is sufficiently flexible for all datastores | 17:57 |
denis_makogon | notamrcn, in this case, we would really need to shutdown the instance | 17:57 |
notamrcn | so, if you recall, my first question on monday was whether this snapshot replication would require a shutdown/reboot | 17:58 |
denis_makogon | notamrcn, but it seems, affects only sql databases | 17:58 |
notamrcn | so, in your implementing this bp, I would like to be reasonably sure that the implementation is one that is later extensible to other data stores | 17:58 |
notamrcn | I can think of multiple ways to structure this code | 17:58 |
notamrcn | and some would be amenable to extension to other datastores and others would be a beast | 17:59 |
notamrcn | which was my (c) question in email | 17:59 |
notamrcn | anyway meetign is supposed to start in 1min | 17:59 |
SlickNik | Hello folks. Time for the meeting in #openstack-meeting-alt. | 17:59 |
*** notamrcn is now known as amrith | 17:59 | |
amrith | \o/ | 18:00 |
amrith | denis_makogon, we have to continue at some point | 18:00 |
denis_makogon | amrith, we're do that after meeting | 18:00 |
*** eguz has joined #openstack-trove | 18:00 | |
*** sbfox has quit IRC | 18:01 | |
*** sbfox has joined #openstack-trove | 18:03 | |
*** amytron has joined #openstack-trove | 18:03 | |
*** eghobo has quit IRC | 18:04 | |
*** shivamshukla has quit IRC | 18:04 | |
*** khyati has joined #openstack-trove | 18:05 | |
*** shivamshukla has joined #openstack-trove | 18:05 | |
amrith | denis_makogon, unfortunately I have a meeting in 52min. by the time that is over it may be too late for you. | 18:08 |
denis_makogon | yeah, amrith we could continue tomorrow, i guess | 18:09 |
*** ramashri has joined #openstack-trove | 18:12 | |
*** todd_dsm has joined #openstack-trove | 18:14 | |
*** thedodd has joined #openstack-trove | 18:15 | |
*** _shalkh has quit IRC | 18:24 | |
*** _shalini_kh has joined #openstack-trove | 18:24 | |
*** coolsvap is now known as coolsvap|afk | 18:26 | |
*** todd_dsm has quit IRC | 18:33 | |
*** SnowDust has left #openstack-trove | 18:39 | |
openstackgerrit | Anna Shen proposed a change to openstack/trove-integration: Add neutron switch for ini tests https://review.openstack.org/87856 | 18:40 |
*** michael-yu has quit IRC | 18:40 | |
*** michael-yu has joined #openstack-trove | 18:40 | |
*** SnowDust has joined #openstack-trove | 18:40 | |
SlickNik | annashen: around? Your topic item is being discussed in #openstack-meeting-alt | 18:45 |
*** SnowDust has quit IRC | 18:50 | |
*** russellb has quit IRC | 18:53 | |
*** _shalini_kh has quit IRC | 18:54 | |
*** russellb has joined #openstack-trove | 18:55 | |
*** sriram_tesora has joined #openstack-trove | 18:57 | |
*** sriram_ has joined #openstack-trove | 19:00 | |
*** demorris has quit IRC | 19:03 | |
*** sriram_tesora has quit IRC | 19:04 | |
*** demorris has joined #openstack-trove | 19:11 | |
denis_makogon | annashen, ping | 19:14 |
denis_makogon | annashen, hope you're there, i guess you're now the owner of the networking in Trove, i would like you to take this review as the base for your future code, it'll save your time, https://review.openstack.org/#/c/86031/ | 19:15 |
denis_makogon | SlickNik, ping | 19:19 |
annashen | denis: pong | 19:19 |
denis_makogon | SlickNik, could you please suggest the way to perform integration testing for the resources that not being tracked by trove https://review.openstack.org/#/c/45075/ ? | 19:20 |
annashen | denis, thanks for your patient, | 19:20 |
denis_makogon | annashen, thanks to you too | 19:20 |
SlickNik | denis_makogon: Add new integration tests to the suite for Floating IPs? | 19:21 |
denis_makogon | annashen, those patch basically refactors code by making it generic and dependent to driver | 19:21 |
SlickNik | denis_makogon: Flavors are not being tracked by trove (in the db, if that's what you mean), yet we have integration tests for them. | 19:22 |
annashen | rather than wasting this patch, do you mind of rebasing it off current master head and i will submit my patch on that | 19:22 |
amrith | denis_makogon, my other meeting is over. we can chat now if you'd like | 19:22 |
denis_makogon | annashen, i cannot do that, because my BP marked as obsolete, it's your task now, feel free to take my patch and submit another that absorbs mine | 19:23 |
denis_makogon | amrith, yes we can | 19:23 |
annashen | denis, thanks! | 19:23 |
denis_makogon | annashen, you're welcome | 19:24 |
annashen | i will do that | 19:24 |
denis_makogon | amrith, we stopped at the question how does each database will act before snapshoting the volume | 19:25 |
amrith | yes, we were approximately there | 19:25 |
amrith | my overarching concern is this | 19:25 |
amrith | your bp postulates that there shall be 3 steps | 19:25 |
amrith | set <something> readonly | 19:25 |
amrith | snapshot volume | 19:25 |
amrith | resume | 19:25 |
amrith | I would like to come up with a set of steps that would (maybe more than 3) work for all datastores | 19:26 |
denis_makogon | agreed, it should be changed | 19:26 |
denis_makogon | what if it'll be like: | 19:26 |
amrith | and something that would work for the same data stores if something changes moving forward | 19:26 |
denis_makogon | 1. prepare database (specific to each datastore) | 19:26 |
amrith | and this impacts the things like assumptions and limitations | 19:26 |
denis_makogon | 2. snapshot | 19:26 |
denis_makogon | 3. resume | 19:26 |
amrith | actually, not that | 19:27 |
amrith | sorry, strike that | 19:27 |
amrith | yes, something like that | 19:27 |
amrith | here's what I had in mind | 19:27 |
denis_makogon | amrith, current backup base class allows to run _pre_backup() and _post_backup() methods | 19:27 |
amrith | 1. ask datastore the list of volumes, locations, etc., that must be snapshotted in one unified set | 19:27 |
amrith | 2. verify that these can be done | 19:28 |
amrith | 3. instruct database to go to readonly mode (with a specified timeout) | 19:28 |
amrith | 4. initiate snapshot | 19:28 |
amrith | 5. inform database that it can resume writing | 19:28 |
*** shivamshukla has quit IRC | 19:28 | |
denis_makogon | i see it another way | 19:28 |
amrith | I think these five would be a set of steps that you can use for all datastores that I can think of right now | 19:28 |
denis_makogon | 1. ask instance for it's volume | 19:29 |
amrith | and in the future we could extend this as required | 19:29 |
*** sbfox has quit IRC | 19:29 | |
denis_makogon | amrith, in this case we would deal with income requirements in the future | 19:29 |
*** michael-yu has quit IRC | 19:30 | |
denis_makogon | amrith, at now instance can have _only_ one volume | 19:30 |
amrith | well, denis_makogon I would make it "it's volumes" | 19:30 |
amrith | yes, now it may be only one | 19:30 |
amrith | but that's not likely to be the case for a production version of a datastore | 19:30 |
denis_makogon | amrith, we're talking about "now", future will come when it will come | 19:30 |
amrith | it is a common gripe with RDS | 19:30 |
amrith | yes, but software will exist in the future | 19:31 |
amrith | the objective is to make an extensible api | 19:31 |
amrith | otherwise it is more work later | 19:31 |
denis_makogon | amrith, DBInstance model that is responsible for Trove instances, has only one attribute: volume_ID | 19:32 |
denis_makogon | nothing else | 19:32 |
*** michael-yu has joined #openstack-trove | 19:32 | |
denis_makogon | we cannot predict everything | 19:32 |
denis_makogon | so, the actual flow will be: | 19:33 |
denis_makogon | 1. ask if instance if it has the volume | 19:33 |
denis_makogon | 2. prepare database for storage snapshot | 19:34 |
denis_makogon | 3. snapshot | 19:34 |
denis_makogon | 4. return database in to the normal state | 19:34 |
amrith | denis_makogon, one second <thinking> | 19:34 |
amrith | ok, sounds good | 19:35 |
amrith | would your infrastructure provide the ability to take a snapshot of multiple trove instances; ie. a consistent snapshot? | 19:36 |
denis_makogon | amrith, please explain | 19:37 |
amrith | and at another level, shouldn't your implementation have an API? | 19:37 |
amrith | re: first question ... | 19:37 |
amrith | suppose I have five trove instances | 19:37 |
amrith | can I get a consistent snapshot of all of them in a single API call? | 19:38 |
denis_makogon | amrith, about API - no, CinderSnapshot is the strategy of the backup process, that has it's own API | 19:38 |
amrith | it would be to run step 1 and 2 on all instances | 19:38 |
amrith | and then run 3 on all instances | 19:38 |
amrith | and then run 4 on all instances | 19:38 |
amrith | so the API would just be the backup API? | 19:38 |
denis_makogon | amrith, https://wiki.openstack.org/wiki/Trove/snapshot-design#Backups_Design | 19:39 |
amrith | because it says no change to public api | 19:39 |
denis_makogon | amrith, of course | 19:39 |
denis_makogon | amrith, no new API routes would be added | 19:39 |
amrith | you would just add a new bkup_type? | 19:39 |
denis_makogon | amrith, yes | 19:39 |
*** mattgriffin is now known as mattgriffin-afk | 19:40 | |
amrith | but the create backup method has no way to specify backup type | 19:40 |
*** sbfox has joined #openstack-trove | 19:40 | |
denis_makogon | amrith, yes, it's config based feature | 19:40 |
amrith | at least in the bp you pointed me to | 19:40 |
*** mattgriffin-afk has quit IRC | 19:41 | |
amrith | oh, so the config would have a setting that says "backup -> xtrabackup" or "backup -> snapshot" | 19:41 |
denis_makogon | i think we would need the new API that lists the available strategies | 19:41 |
denis_makogon | amrith, yes | 19:41 |
amrith | ok, maybe you could add that to your bp | 19:41 |
denis_makogon | amrith, no, it's anothe BP | 19:41 |
denis_makogon | amrith, totally different scope | 19:42 |
amrith | I guess I don't understand that | 19:42 |
amrith | how does one get a snapshot backup? | 19:42 |
amrith | at the very least you have a depenency to that "other bp" | 19:42 |
openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Added route for Admin API to support guest upgrade https://review.openstack.org/81410 | 19:42 |
denis_makogon | amrith, now i don't have any dependency at any BPs | 19:43 |
amrith | well, maybe you should? | 19:43 |
denis_makogon | amrith, no, why would i ? | 19:43 |
denis_makogon | amrith, features are totally independent, why should they be dependent? | 19:44 |
amrith | so if there's no new API (RequestSnapshotBackup, for example) then how do I get a snapshot backup? | 19:45 |
denis_makogon | amrith, my BP proposes to add new backup type | 19:45 |
denis_makogon | amrith, to the end user there's no difference | 19:45 |
denis_makogon | amrith, user performs the backup | 19:45 |
denis_makogon | amrith, he doesn't know how its being performed | 19:46 |
*** amcrn_ has joined #openstack-trove | 19:46 | |
amrith | denis_makogon, where does your BP propose new backup type (I'm reading https://wiki.openstack.org/wiki/Trove/volume-data-snapshot-design) | 19:46 |
amrith | so, if a user performs a backup today, he would get an xtradb backup, yes? | 19:46 |
amrith | sorry xtrabackup | 19:47 |
denis_makogon | amrith, justification section | 19:47 |
denis_makogon | amrith, yes | 19:47 |
*** amcrn has quit IRC | 19:47 | |
amrith | so what would be changed to make this snapshot backup available to a user? | 19:48 |
*** ViswaV_ has quit IRC | 19:48 | |
*** amcrn_ is now known as amcrn | 19:48 | |
amrith | something has to change, otherwise we'd get an xtrabackup, right? | 19:48 |
*** ViswaV has joined #openstack-trove | 19:48 | |
amrith | and I have no idea what happens for a backup of mongodb or cassandra or some other datastore | 19:48 |
denis_makogon | amrith, nothing, user can't see the difference between backup(xtrabackup) and another made by cinder | 19:49 |
amrith | well, not to the user | 19:49 |
amrith | what causes the code to execute snapshot backup and not xtrabackup? | 19:49 |
denis_makogon | amrith, only guest config rules | 19:49 |
amrith | so the config would have a setting that says "backup -> xtrabackup" or "backup -> snapshot" | 19:50 |
denis_makogon | amrith, https://github.com/openstack/trove/blob/master/trove/common/cfg.py#L272 | 19:50 |
denis_makogon | amrith, yes | 19:50 |
denis_makogon | amrith, strategies are being switched through guest configuration file | 19:51 |
amrith | ok, so what I'm requesting is just that you clarify this in your BP. and that there should be an API that lists the possible strategies. | 19:51 |
glucas | demorris, amrith: so currently a guest is configured to enable a single backup strategy.. but in the future we could use e.g. capabilities so that a datastore can support multiple strategies, and user could choose which to run? | 19:53 |
denis_makogon | amrith, at least now we don't need that type of the API | 19:53 |
amrith | the latter was your suggestion (some minutes ago), I don't want to take credit for it. | 19:53 |
glucas | whoops ^ denis_makogon , sorry demorris | 19:53 |
amrith | de<TAB> | 19:53 |
glucas | yeah | 19:53 |
denis_makogon | glucas, i suppose yes | 19:54 |
*** saurabhs has joined #openstack-trove | 19:54 | |
denis_makogon | glucas, at least we could implement the API that asks Trove which strategies available for {datastore} | 19:54 |
denis_makogon | amrith, are we ok with BP now ? | 19:55 |
amrith | well, I guess those were the questions I sent you in email. I don't know that I'm happy with the answers (personally, I'd implement a more flexible system but I'm not the one implementing it). And so it is up to core whether they like this BP or not. I'm not happy with it. But, I'm also not happy with the fact that I'm overweight. | 19:56 |
amrith | And 'core' won't help me with that either ;) | 19:56 |
amrith | denis_makogon, I have to run now (as in go somewhere, not run. running is IMHO bad). g'night | 19:58 |
denis_makogon | amrith, feel free to submit the BP and spec to any feature you want to fix or implement | 19:58 |
*** thedodd has quit IRC | 19:59 | |
*** NehaV1 has joined #openstack-trove | 19:59 | |
*** NehaV has quit IRC | 20:00 | |
*** demorris has quit IRC | 20:02 | |
*** Barker has quit IRC | 20:02 | |
*** khyati_ has joined #openstack-trove | 20:03 | |
*** khyati has quit IRC | 20:04 | |
*** thedodd has joined #openstack-trove | 20:05 | |
*** Barker has joined #openstack-trove | 20:07 | |
*** ViswaV has quit IRC | 20:11 | |
*** Barker has quit IRC | 20:12 | |
*** Barker has joined #openstack-trove | 20:14 | |
*** ramashri has quit IRC | 20:14 | |
mat-lowery | https://wiki.openstack.org/wiki/Meetings/TroveMeeting doesn't state a time and place for the blueprint meetings. Can someone edit that or let me know and I'll edit it? | 20:16 |
esp | mat-lowery: I think the bp meetings are mondays in the #openstack-trove channel in the morning 10-11ish. SlickNik or amcrn could confirm I think | 20:18 |
*** NehaV1 has quit IRC | 20:19 | |
*** NehaV has joined #openstack-trove | 20:19 | |
SlickNik | mat-lowery: 11-12 Mondays in #openstack-trove | 20:20 |
mat-lowery | thanks esp and SlickNik: so same time as weekly meetings ok | 20:22 |
mat-lowery | I'll edit if that is ok | 20:22 |
esp | thx mat-lowery, that’s a good idea | 20:23 |
SlickNik | mat-lowery: Awesome. Thanks! | 20:24 |
*** mattgriffin has joined #openstack-trove | 20:24 | |
*** radez_g0n3 has quit IRC | 20:26 | |
*** radez_g0n3 has joined #openstack-trove | 20:26 | |
mat-lowery | esp, SlickNik: done. thank you! | 20:27 |
*** mattgriffin has quit IRC | 20:29 | |
*** sbfox has quit IRC | 20:32 | |
*** sbfox has joined #openstack-trove | 20:38 | |
*** michael-yu has quit IRC | 20:39 | |
*** sbfox has quit IRC | 20:45 | |
*** michael-yu has joined #openstack-trove | 20:47 | |
*** sbfox has joined #openstack-trove | 20:47 | |
*** mattgriffin has joined #openstack-trove | 20:48 | |
*** eguz has quit IRC | 20:49 | |
*** eghobo has joined #openstack-trove | 20:50 | |
*** ramashri has joined #openstack-trove | 20:58 | |
*** jmontemayor has quit IRC | 21:07 | |
*** casanch1_ has joined #openstack-trove | 21:14 | |
*** amytron_ has joined #openstack-trove | 21:14 | |
*** amytron has quit IRC | 21:14 | |
*** amytron_ is now known as amytron | 21:14 | |
*** casanch1 has quit IRC | 21:17 | |
*** casanch1_ has quit IRC | 21:18 | |
openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Added separate rate limit setting for mgmt POST https://review.openstack.org/81557 | 21:20 |
*** kevinconway has quit IRC | 21:23 | |
*** denis_makogon has quit IRC | 21:24 | |
*** grapex_ has joined #openstack-trove | 21:25 | |
*** grapex has quit IRC | 21:28 | |
*** pdmars has quit IRC | 21:28 | |
*** eguz has joined #openstack-trove | 21:29 | |
*** robertmyers has quit IRC | 21:32 | |
*** eghobo has quit IRC | 21:34 | |
*** achampion has quit IRC | 21:34 | |
*** Barker has quit IRC | 21:38 | |
*** ViswaV has joined #openstack-trove | 21:39 | |
*** NehaV has quit IRC | 21:39 | |
*** ViswaV_ has joined #openstack-trove | 21:40 | |
*** ViswaV has quit IRC | 21:43 | |
esmute | amcrn, SlickNik: I was thinking about the cross-region backup. There is really no use of specifying the availability_zone. As long as the region is given, the backup object can be accessed to. | 21:52 |
esmute | Availability zone is more for swift object placement, which trove doesnt really care about | 21:52 |
esmute | https://wiki.openstack.org/wiki/Cross-region-backup-availability | 21:52 |
*** jcru has quit IRC | 21:52 | |
*** sriram_ has quit IRC | 21:53 | |
esmute | im thinking of removing the availability_zone from the api ^ | 21:53 |
esmute | what do you guys think? | 21:53 |
*** demorris has joined #openstack-trove | 21:56 | |
*** demorris has quit IRC | 22:02 | |
*** amytron has quit IRC | 22:06 | |
*** michael-yu has quit IRC | 22:13 | |
esp | SlickNik: ping | 22:14 |
openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Added separate rate limit setting for mgmt POST https://review.openstack.org/81557 | 22:15 |
openstackgerrit | Dan Nguyen proposed a change to openstack/trove: Add a new column and indexes to agent_heartbeats https://review.openstack.org/81682 | 22:15 |
SlickNik | esp: 'sup? | 22:15 |
*** NehaV has joined #openstack-trove | 22:15 | |
esp | SlickNik: was wondering if you knew of this error in the reddwarf gate https://rdjenkins.dyndns.org/job/Trove-Gate/3269/console | 22:15 |
esp | I just tried rebasing to see if that would do the trick.. | 22:16 |
SlickNik | esp: yes rebasing should fix it. | 22:17 |
esp | k, thx! | 22:17 |
SlickNik | It's a side effect of some new checks that went into the requirements package upstream. We now fail if you're trying to use a requirement that's not part of the global requirements. | 22:18 |
SlickNik | Rebasing should get your requirements in line. | 22:18 |
SlickNik | No problem. | 22:18 |
esp | sounds good | 22:23 |
*** NehaV has quit IRC | 22:31 | |
*** grapex_ has quit IRC | 22:36 | |
*** grapex has joined #openstack-trove | 22:36 | |
SlickNik | esmute: Just saw your comment about the AZ. I think that's a fair point. I'm good with that (i.e. not specifying AZ as part of the request) | 22:39 |
*** yogesh has quit IRC | 22:40 | |
*** mattgriffin has quit IRC | 22:41 | |
*** thedodd has quit IRC | 22:41 | |
amrith | esp, for my edification, are you going to remove az from the api or make it not required [optional, assming it is now required]? | 22:43 |
esp | amrith: hello, can you remind me which bp that please? | 22:43 |
esp | amrith: I think you might be thinking esmute :) | 22:44 |
amrith | esp, I was going to say something clever to SlickNik about tab completion. turns out I did it ;) | 22:44 |
amrith | yes, esmute | 22:44 |
amrith | es<TAB>, for my edification, are you going to remove az from the api or make it not required [optional, assming it is now required]? | 22:44 |
*** sbfox has quit IRC | 22:45 | |
amrith | esp, I'm otherwise known as notamcrn | 22:45 |
esmute | amrith: edification? that is a big word :) | 22:45 |
amrith | 10 points in scrabble | 22:45 |
esmute | yes. i was suggesting to remove az from the api completely | 22:45 |
amrith | esmute, thanks. | 22:46 |
esmute | im about to update the wiki... that will make it cleary | 22:46 |
esp | haha | 22:46 |
amcrn | +1 to removing az from the api completely | 22:46 |
esp | esmute: so your cross region support for backups is more about the ability to put the backup in east or west? | 22:47 |
amrith | esmute, reason I ask is that if there was a parameter and you now remove it, it could break an application (not like someone is using it yet, maybe). I was wondering whether the convention in openstack was to make it deprecated first (for a release) and then remove it or just remove it. Thx! | 22:47 |
esmute | esp: Yes... more like it allows to copy backups from west to east and viceversa... | 22:47 |
esp | esmute: meaning you don’t necessarily care which AZ in falls under | 22:47 |
amrith | amcrn, this won't be a compat issue for all-o-y'all? | 22:48 |
esmute | esp: yes :) | 22:48 |
esp | esmute: k, does this make it difficult to retrieve it? | 22:48 |
amcrn | amrith: it might be for some, but not for us | 22:48 |
esp | esmute: or is it recorded somewhere like the DB or name of the backup? | 22:48 |
amrith | ok, mostly educational question on my part. I've worked at places where it is three releases before you can change an API in an incompatible way and releases were annual ;) | 22:48 |
amrith | sorry, not places. one place | 22:49 |
esp | amrith: me too | 22:49 |
esmute | amrith: yes you are correct.. im able to mess around the api because no one is using it... but for openstack, usually changes api are marked deprecated but are still backward compatible between minor releases.. | 22:49 |
esmute | between major releases, it is a different thing | 22:49 |
amrith | would this mean that we would rev our API for this kind of change? | 22:50 |
amrith | i.e bump the api revision? | 22:50 |
esmute | amrith: once we have versionining in our API, yes | 22:50 |
SlickNik | Okay, I need a clarification here. esmute: isn't this an addition to the existing API that we're proposing? | 22:51 |
amcrn | esp: i'm pretty sure az is a just a pass-thru to nova if memory serves me correctly | 22:51 |
*** lnxnut_ has joined #openstack-trove | 22:51 | |
*** lnxnut has quit IRC | 22:51 | |
*** lnxnut_ has quit IRC | 22:51 | |
esp | amcrn: cool. I thought that if you don’t specify it just chooses for you. | 22:52 |
*** lnxnut has joined #openstack-trove | 22:52 | |
esp | amcrn: but maybe that’s a configurable thing in nova | 22:52 |
esmute | esp: the backups are no recorded in the DB in the new region. The DB record is created and populated with the information from the swift metadata... the metadata holds some informatino about the backup | 22:52 |
esp | esmute: gotcha | 22:53 |
esmute | SlickNik: Yes. it is.. | 22:53 |
amrith | esmute, touche ;) | 22:53 |
esmute | SlickNik: I am overloading the Backup create and have it receive a backup id and region | 22:54 |
esp | esmute: so makes no difference then, meaning amcrn is correct when he says pass-thru | 22:54 |
esmute | SlickNik: let me know if i answer your question | 22:54 |
esp | thx amcrn show me up again… | 22:54 |
* amcrn moonwalks | 22:54 | |
esmute | lol amcrn | 22:55 |
amcrn | ;) | 22:55 |
esmute | esp: I think swift may have concept of zones...where you can choose where the objects go... but im not too sure | 22:55 |
SlickNik | esmute: Yes. | 22:56 |
esp | esmute: yeah but if all you need to do is ask swift for an object from a container and it knows what to do then I think you got it under control | 22:56 |
esp | good work esmute :) | 22:56 |
*** todd_dsm has joined #openstack-trove | 22:57 | |
esp | damn 4:00p already... | 22:57 |
esmute | esp: Thanks .. we'll see how it turns out | 22:57 |
amrith | well, it was 4pm here a long time ago | 22:57 |
amrith | just saying, it's almost 7 | 22:57 |
esp | amrith: haha, true | 22:57 |
amrith | we start at 5pm here | 22:57 |
amrith | now looking to see where the next pub is | 22:57 |
amrith | enjoy folks! | 22:57 |
esmute | chao amrith | 22:58 |
esp | peace amrith :) | 22:58 |
amrith | esmute, esp have fun (and in an hour, have a beer) | 22:58 |
amrith | SlickNik, you around still? | 22:58 |
esp | thx amrith, yeah I need a drink | 22:58 |
SlickNik | So just to recap so we're on the same page. esmute feel free to correct any of this: | 22:59 |
SlickNik | - We're proposing an addition to the backup API | 22:59 |
SlickNik | - The modification (removal of AZ) is a modification to the proposed API | 22:59 |
SlickNik | - It's not a modification to the backup API as it exists today | 22:59 |
SlickNik | - Hence it doesn't affect backwards compat or the previous backup API | 22:59 |
SlickNik | amrith: Yup, I'm around | 22:59 |
esmute | SlickNik: Correcto... | 23:00 |
esmute | it is a modification of a new proposed API.... | 23:00 |
esmute | which havent been used yet | 23:00 |
esmute | SlickNik: actually i lied | 23:07 |
esmute | the trove client does have a change in the cli | 23:07 |
esmute | currently in the cli, we use 'trove backup-create <name> <instance>' to create a backup | 23:08 |
esmute | <instance> has to be made optional now | 23:08 |
esmute | so it would change to 'trove backup-create <name> --instance <instance>' | 23:09 |
*** todd_dsm has quit IRC | 23:09 | |
*** todd_dsm has joined #openstack-trove | 23:10 | |
esmute | is there a way to make the arg param optional....without making it a kward | 23:11 |
esmute | *kwarg | 23:11 |
SlickNik | not that I'm aware of. | 23:11 |
*** michael-yu has joined #openstack-trove | 23:13 | |
esmute | ok.. let me see if i can find a way | 23:14 |
SlickNik | Yeah, let's think through this a bit more. I understand that the API contract (i.e. the URI and payload body) will stay the same. But I'm not too excited about the troveclient command line syntax changing. | 23:17 |
esmute | yeah. i am with you | 23:18 |
esmute | but currently, an instance_id will have to be specified. | 23:18 |
esmute | we can overload the 2nd arg to get an ID... whther it is an isntance id or backup id | 23:19 |
esmute | but that could be confusing. | 23:19 |
SlickNik | Maybe we add a different command to the client that maps to the same route with the new payload? | 23:20 |
SlickNik | Just a thought | 23:20 |
SlickNik | trove backup-create-from-copy or something? | 23:20 |
esmute | because we have to provide an ID.. whether it is an instance id or a backup id | 23:20 |
esmute | SlickNik: That could also work | 23:21 |
SlickNik | Then we could leave the current command the way it is. | 23:21 |
esmute | actually.. what i proposed doesnt seem too bad.. | 23:21 |
esmute | the api stays the same, but the doc will change | 23:22 |
esmute | instead of saying "instance id" it will say "source id" | 23:22 |
SlickNik | That's not a bad option either. The help string will need to change. | 23:22 |
SlickNik | Yup. | 23:22 |
*** ramashri has quit IRC | 23:23 | |
esmute | then it is up to trove how to diferentiate which ID it is... | 23:23 |
amrith | SlickNik, (again for edification) are you not happy with the command line syntax changing (period) or that the change would be incompatible? | 23:24 |
esmute | actually.. that is too confusing and more work.. i think your suggestion is better | 23:24 |
*** flaper87 is now known as flaper87|afk | 23:25 | |
esmute | i am leaning on create a new cli API | 23:25 |
SlickNik | amrith: I don't think the change would be incompatible. (i.e. all previous trove backup API calls would remain exactly the same and do the same thing). | 23:25 |
amrith | i see, in other words the second argument (which is now an instance_id) would in future be an id (either instance or backup) and it's up to the backend implementation to figure out which | 23:26 |
amrith | and since it is an id, it damn well be unique ;) | 23:26 |
amrith | is that right? | 23:26 |
SlickNik | esmute: was trying to overload the current backup-create command in the trove client to cater to the new scenario he's adding, and that would change the client syntax. And I wouldn't like to do that. | 23:27 |
SlickNik | amrith: Actually I don't think the backend should decide that. That seems like API creep. | 23:27 |
amrith | I guess that's what I'm not following | 23:28 |
amrith | the api has an argument that could be overloaded? | 23:28 |
amrith | but the CLI would have two options, backup_id and instance_id and stuff the value of one or the other into that argument? | 23:29 |
SlickNik | amrith: no. The API does something different based on the payload. | 23:29 |
amrith | SlickNik, esmute ... sorry if I'm slowing your conversation down ... | 23:29 |
amrith | ok, I guess I was calling that the implementation of the API | 23:30 |
*** grapex has quit IRC | 23:31 | |
*** ranjitha has joined #openstack-trove | 23:33 | |
SlickNik | What I initially suggested, was to add a new command to the cli for this new scenario. The fact that it's using the same route internally with a new payload would just be an internal implementation detail. | 23:34 |
esmute | SlickNik: +1. I dont like this APi creep either.. i think your suggestion (creating a new command CLI) is better | 23:35 |
*** ViswaV_ has quit IRC | 23:35 | |
amrith | esmute, and the new CLI would accept the new kind of ID? | 23:35 |
esmute | amrith: yes.. backup id to be precise.... | 23:36 |
esmute | the other api (the current one) aaccepts instance id. | 23:36 |
*** achampion has joined #openstack-trove | 23:36 | |
amrith | esumte, but it would still make the same backend call, putting the backup_id in the place where the other CLI API would put the instance_id? | 23:36 |
esmute | they share the same API route, but internally, they are being handled differently | 23:36 |
amrith | OK, I will try and understand that some more; what you mean by API route. Thanks guys for humoring me, I'm hoping to learn more of this stuff by listening to y'all chat. | 23:37 |
SlickNik | amrith: They call them out explicitly as being two different types of ID in the payload. | 23:37 |
*** mattgriffin has joined #openstack-trove | 23:37 | |
SlickNik | Let me see if I can get a quick example | 23:37 |
SlickNik | one sec. | 23:37 |
amrith | SlickNik, ok, that would be two API's and thanks for offering an example | 23:37 |
esmute | amrith: when i said 'route', i meant the REST API... that will stay unchanged.. | 23:38 |
*** todd_dsm has quit IRC | 23:38 | |
amrith | esmute, same route (same REST API), but you could either provide backup_id=...... or isntance_id=...... and the backend did different things base don that? | 23:39 |
amrith | s/isntan/instan/ | 23:39 |
esmute | amrith: yes | 23:39 |
amrith | esmute, thanks. I understand. thx much | 23:40 |
*** ranjitha has quit IRC | 23:40 | |
amrith | and sorry for derailing ur converstaion | 23:40 |
amrith | conversation | 23:40 |
esmute | no.. this is good... i feel like amcrn... moonwalking.. | 23:40 |
amrith | amcrn is on the moon now? | 23:41 |
amrith | didn't know they had irc there | 23:41 |
amrith | ;) | 23:41 |
esmute | he was... but i think he's come back down now | 23:41 |
amrith | oh, he bought the economy round trip ticket | 23:41 |
amrith | good move | 23:41 |
amrith | I hear the food on the moon isn't that good | 23:42 |
amrith | some friends went there | 23:42 |
amrith | they came back too | 23:42 |
esmute | amrith: They only have cheese there. | 23:42 |
amrith | well, they were vegan which would explain the issue | 23:42 |
amrith | issue, problem, same thing | 23:42 |
esmute | lol | 23:43 |
SlickNik | quick gist: https://gist.github.com/anonymous/2d5d70e39c5aa60baec9 | 23:46 |
amrith | looking | 23:47 |
SlickNik | esmute, feel free to correct if I'm off with the proposed piece, just cobbled that together since it doesn't exist. | 23:47 |
amrith | SlickNik, thanks for the example | 23:49 |
amrith | i learnt something noo ... | 23:49 |
esmute | SlickNik: This is correct | 23:50 |
esmute | to add to this, there will be two CLI commands, one that populates the first rest request (currently) and another one that will create the second requests (minus the availability_zone) | 23:51 |
SlickNik | np, glad to be of help. | 23:53 |
SlickNik | brb | 23:53 |
esmute | in the server side, trove will parse the payload, if it finds backup["instance"] in the message, then it knows the user wants to create a new instance backup... if it finds backup['backup'] then the user wants a backup from a backup, which is the new feature im implementing | 23:53 |
esmute | this is confusing now.. but i am hoping it becomes more clear when you see the code | 23:54 |
amrith | ok esmute, since SlickNick is not here (and I tend to wear out my welcome), I have a question for you. why a new CLI command | 23:54 |
amrith | so here's what I'm thinking | 23:54 |
amrith | <command> <instance_id> .... works like now | 23:54 |
amrith | command --instance_id <instance_id> .... new implementation, same as old one | 23:54 |
amrith | <command> --backup_id <backup_id> ... new implementation | 23:55 |
amrith | and they'd use the new API or the old one | 23:55 |
amrith | no new command | 23:55 |
amrith | just changed CLI | 23:55 |
amrith | in a compatible way | 23:55 |
esmute | let me play it back.. because i tend not to get things quickly | 23:57 |
esmute | <command> <instance_id> .... works like now | 23:57 |
amrith | or | 23:57 |
esmute | command --instance_id <instance_id> --backup_id <backup_id>.... new implementation that i proposed, command is the same as old one... but the --instance_id and --backup_id are both optional | 23:58 |
SlickNik | back | 23:58 |
esmute | new_command <backup_id> is what SlickNik proposed | 23:58 |
amrith | esmute, that was what I was thinking [almost]. either instance_id or backup_id must be provided. instance_id can be be provided either with or without --instance_id | 23:58 |
amrith | ah, so slicknick proposed | 23:59 |
amrith | <oldcommand> instance_id | 23:59 |
amrith | <newcommand> backup_id | 23:59 |
amrith | I see | 23:59 |
amrith | ok | 23:59 |
esmute | amrith: if we go to the command i proposed, the instance_id cannot be passed without the --instance_id | 23:59 |
SlickNik | amrith: I think the cli has a limitation where if you have a positional arg (i.e. not a —kwarg) it's also a required arg for the command. | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!