| *** Riddhi has quit IRC | 00:09 | |
| *** topshare has joined #openstack-trove | 00:54 | |
| *** nosnos has joined #openstack-trove | 01:01 | |
| *** X019 has joined #openstack-trove | 01:19 | |
| *** tomblank has joined #openstack-trove | 01:29 | |
| openstackgerrit | Li Ma proposed openstack/trove: Add nova_proxy_admin_tenant_id to make nova_compute_url effective https://review.openstack.org/111679 | 01:53 |
|---|---|---|
| *** haomaiwa_ has quit IRC | 01:55 | |
| *** haomaiwa_ has joined #openstack-trove | 02:17 | |
| *** annashen has joined #openstack-trove | 02:22 | |
| *** X019 has quit IRC | 02:32 | |
| *** erkules_ has joined #openstack-trove | 02:39 | |
| *** erkules has quit IRC | 02:42 | |
| *** X019 has joined #openstack-trove | 02:44 | |
| *** fifieldt has quit IRC | 02:45 | |
| *** annashen has quit IRC | 02:56 | |
| *** Longgeek has joined #openstack-trove | 03:28 | |
| *** Longgeek has quit IRC | 03:33 | |
| *** nosnos has quit IRC | 03:49 | |
| *** ramishra has joined #openstack-trove | 03:51 | |
| *** rushiagr_away is now known as rushiagr | 04:22 | |
| *** vigneshvar has joined #openstack-trove | 04:25 | |
| *** vigneshvar has quit IRC | 04:31 | |
| *** newb has quit IRC | 04:32 | |
| *** annashen has joined #openstack-trove | 04:35 | |
| *** annashen has quit IRC | 04:39 | |
| *** Longgeek has joined #openstack-trove | 04:44 | |
| *** nosnos has joined #openstack-trove | 04:46 | |
| *** vigneshvar has joined #openstack-trove | 04:46 | |
| *** Longgeek has quit IRC | 04:48 | |
| *** sgotliv has joined #openstack-trove | 05:26 | |
| *** Longgeek has joined #openstack-trove | 05:37 | |
| *** nosnos_ has joined #openstack-trove | 05:50 | |
| *** nosnos has quit IRC | 05:51 | |
| *** nosnos_ has quit IRC | 05:57 | |
| *** nosnos has joined #openstack-trove | 05:59 | |
| *** hogepodge has quit IRC | 06:01 | |
| *** Longgeek has quit IRC | 06:17 | |
| *** Longgeek has joined #openstack-trove | 06:18 | |
| *** Longgeek_ has joined #openstack-trove | 06:18 | |
| *** sgotliv has quit IRC | 06:20 | |
| *** miqui has quit IRC | 06:22 | |
| *** Longgeek has quit IRC | 06:22 | |
| *** tomblank has quit IRC | 06:23 | |
| *** nosnos_ has joined #openstack-trove | 06:23 | |
| *** nosnos has quit IRC | 06:23 | |
| *** hogepodge has joined #openstack-trove | 06:24 | |
| *** erkules_ is now known as erkules | 06:42 | |
| *** exploreshaifali has joined #openstack-trove | 06:47 | |
| *** Longgeek_ has quit IRC | 06:56 | |
| *** Longgeek has joined #openstack-trove | 06:57 | |
| openstackgerrit | Merged openstack/trove: Increase instances.task_description column size https://review.openstack.org/111560 | 07:02 |
| *** miqui_ has quit IRC | 07:22 | |
| *** Longgeek has quit IRC | 07:27 | |
| *** Longgeek has joined #openstack-trove | 07:28 | |
| *** exploreshaifali has quit IRC | 07:39 | |
| *** Longgeek_ has joined #openstack-trove | 07:41 | |
| *** exploreshaifali has joined #openstack-trove | 07:41 | |
| *** Longgeek has quit IRC | 07:45 | |
| *** ramishra has quit IRC | 07:46 | |
| *** exploreshaifali has quit IRC | 08:02 | |
| *** exploreshaifali has joined #openstack-trove | 08:05 | |
| *** fifieldt has joined #openstack-trove | 08:09 | |
| *** exploreshaifali has quit IRC | 08:16 | |
| *** ajayaa has joined #openstack-trove | 08:24 | |
| *** romainh has joined #openstack-trove | 08:57 | |
| *** boblebauce has joined #openstack-trove | 09:20 | |
| *** sgotliv has joined #openstack-trove | 09:20 | |
| *** ramishra_ has joined #openstack-trove | 09:31 | |
| *** ramishra_ has quit IRC | 09:32 | |
| *** ramishra_ has joined #openstack-trove | 09:41 | |
| *** ramishra_ has quit IRC | 09:41 | |
| *** flaper87 has quit IRC | 09:43 | |
| *** flaper87 has joined #openstack-trove | 09:43 | |
| openstackgerrit | Merged openstack/trove: Update and correct documentation snippets https://review.openstack.org/132365 | 09:45 |
| *** isviridov_away is now known as isviridov | 09:49 | |
| *** sgotliv has quit IRC | 09:57 | |
| *** ajayaa has quit IRC | 09:59 | |
| *** pboros has joined #openstack-trove | 10:00 | |
| *** haomaiwa_ has quit IRC | 10:34 | |
| *** topshare has quit IRC | 10:34 | |
| *** prasoon has joined #openstack-trove | 10:38 | |
| *** exploreshaifali has joined #openstack-trove | 10:52 | |
| *** denis_makogon has joined #openstack-trove | 10:55 | |
| *** prasoon has quit IRC | 10:55 | |
| *** ajayaa has joined #openstack-trove | 11:04 | |
| *** vigneshvar has quit IRC | 11:30 | |
| *** ajayaa has quit IRC | 11:34 | |
| *** vkmc has joined #openstack-trove | 11:38 | |
| *** openstackgerrit has quit IRC | 11:48 | |
| *** openstackgerrit has joined #openstack-trove | 11:49 | |
| *** ajayaa has joined #openstack-trove | 11:49 | |
| *** sgotliv has joined #openstack-trove | 12:09 | |
| *** IanGovett has joined #openstack-trove | 12:38 | |
| *** nosnos_ has quit IRC | 12:39 | |
| openstackgerrit | Denis M. proposed openstack/trove-specs: Added Cassandra cluster spec https://review.openstack.org/122736 | 12:43 |
| *** sgotliv has quit IRC | 12:47 | |
| openstackgerrit | Denis M. proposed openstack/python-troveclient: Adding --os-auth-token argument https://review.openstack.org/110925 | 12:48 |
| *** exploreshaifali has quit IRC | 12:55 | |
| *** ajayaa has quit IRC | 12:56 | |
| *** sgotliv has joined #openstack-trove | 13:01 | |
| *** rushiagr is now known as rushiagr_away | 13:12 | |
| *** amrith is now known as _amrith_ | 13:16 | |
| *** k4n0_ has quit IRC | 13:39 | |
| *** pdmars_ is now known as pdmars | 13:42 | |
| *** tomblank has joined #openstack-trove | 13:50 | |
| *** jcru has joined #openstack-trove | 13:53 | |
| *** miqui has joined #openstack-trove | 14:10 | |
| *** vigneshvar has joined #openstack-trove | 14:23 | |
| *** johnma has joined #openstack-trove | 14:23 | |
| *** newb has joined #openstack-trove | 14:31 | |
| *** Barker has joined #openstack-trove | 14:36 | |
| openstackgerrit | Denis M. proposed openstack/trove-integration: Fix pre-install.d scripts for mysql/percona https://review.openstack.org/134950 | 14:37 |
| *** robertmy_ has quit IRC | 14:38 | |
| *** robertmyers has joined #openstack-trove | 14:39 | |
| *** rushiagr_away is now known as rushiagr | 14:44 | |
| *** _amrith_ is now known as amrith | 14:46 | |
| *** johnma has quit IRC | 14:53 | |
| *** Longgeek_ has quit IRC | 14:59 | |
| denis_makogon | SlickNik, amrith, hey, guys, our destack-gate faced with problem, https://bugs.launchpad.net/trove-integration/+bug/1393430 | 15:03 |
| *** radez_g0n3 is now known as radez | 15:05 | |
| *** exploreshaifali has joined #openstack-trove | 15:16 | |
| *** grapex has joined #openstack-trove | 15:25 | |
| *** topshare has joined #openstack-trove | 15:30 | |
| *** ramishra_ has joined #openstack-trove | 15:36 | |
| *** ramishra_ has quit IRC | 15:36 | |
| *** robertmyers has quit IRC | 15:36 | |
| *** Riddhi has joined #openstack-trove | 15:40 | |
| *** Riddhi has quit IRC | 15:40 | |
| *** Riddhi has joined #openstack-trove | 15:41 | |
| *** johnma has joined #openstack-trove | 15:44 | |
| *** radez is now known as radez_g0n3 | 15:45 | |
| *** sriram_tesora has joined #openstack-trove | 15:47 | |
| *** jmontemayor has joined #openstack-trove | 15:48 | |
| amrith | is there a trove BP meeting today? the agenda page says it is canceled for today (Nov 17th) | 15:51 |
| amrith | https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting | 15:51 |
| amrith | and there's already an agenda for 24th. | 15:52 |
| *** rwsu has joined #openstack-trove | 15:56 | |
| *** mattgriffin has joined #openstack-trove | 15:56 | |
| denis_makogon | amrith, there was no email from SlickNik about canceling meeting for today, unless i'm missing something | 15:57 |
| amrith | denis_makogon, I'm just going by the web page. not sure why it is canceled but I haven't looked hard either. | 15:59 |
| denis_makogon | amrith, i'd say that someone changed date of previous meeting (Nov. 10 and it was canceled) to new date | 16:00 |
| *** jasonb365 has joined #openstack-trove | 16:00 | |
| *** thedodd has joined #openstack-trove | 16:01 | |
| *** radez_g0n3 is now known as radez | 16:04 | |
| *** tomblank has quit IRC | 16:05 | |
| *** sriram_tesora has quit IRC | 16:09 | |
| *** david-lyle_afk is now known as david-lyle | 16:11 | |
| denis_makogon | romainh, hi there, i've made those changes that you've been asking for, take a look please, https://review.openstack.org/#/c/122736/ =) | 16:15 |
| romainh | denis_makogon: hi Denis! ok done ;) | 16:28 |
| *** Riddhi_ has joined #openstack-trove | 16:28 | |
| *** Riddhi has quit IRC | 16:29 | |
| *** boblebauce has quit IRC | 16:29 | |
| denis_makogon | romainh, thanks! | 16:30 |
| denis_makogon | romainh, if it's ok for you could you please +1 it ? | 16:30 |
| romainh | denis_makogon: ok | 16:30 |
| *** johnma has quit IRC | 16:30 | |
| sgotliv | romainh, denis_makogon or -1 | 16:31 |
| *** pboros has quit IRC | 16:31 | |
| denis_makogon | sgotliv, sure, if it's bad =)) | 16:31 |
| sgotliv | denis_makogon, why bad. not good enough | 16:32 |
| sgotliv | :-) | 16:32 |
| denis_makogon | sgotliv, hah, sure =) | 16:33 |
| *** sriram_tesora has joined #openstack-trove | 16:34 | |
| *** boblebauce has joined #openstack-trove | 16:34 | |
| *** jasonb365 has quit IRC | 16:35 | |
| openstackgerrit | Peter Stachowski proposed openstack/trove: Mark certain configuration options as deprecated https://review.openstack.org/124846 | 16:36 |
| openstackgerrit | Peter Stachowski proposed openstack/trove: Deleting failed replication backup can hide error https://review.openstack.org/131593 | 16:41 |
| *** tomblank has joined #openstack-trove | 16:50 | |
| openstackgerrit | Zhi Yan Liu proposed openstack/trove: Integrate OSprofiler and Trove https://review.openstack.org/116653 | 16:52 |
| *** jasonb365 has joined #openstack-trove | 16:53 | |
| *** haomaiwang has joined #openstack-trove | 16:54 | |
| *** johnma has joined #openstack-trove | 16:56 | |
| *** Riddhi_ has quit IRC | 17:03 | |
| *** rwsu has quit IRC | 17:03 | |
| *** tomblank has quit IRC | 17:03 | |
| *** jasonb365_ has joined #openstack-trove | 17:04 | |
| *** jasonb365 has quit IRC | 17:05 | |
| *** jasonb365_ is now known as jasonb365 | 17:05 | |
| *** tomblank has joined #openstack-trove | 17:08 | |
| openstackgerrit | Zhi Yan Liu proposed openstack/python-troveclient: Add profiling support to Trove client https://review.openstack.org/116654 | 17:11 |
| zhiyan | denis_makogon: hey, i rebased osprofiler patch for trove&troveclient, thanks for your review. | 17:13 |
| *** rwsu has joined #openstack-trove | 17:16 | |
| *** rwsu has quit IRC | 17:18 | |
| *** rwsu has joined #openstack-trove | 17:19 | |
| *** sgotliv has quit IRC | 17:19 | |
| SlickNik | amrith: There is a trove BP meeting today. Someone changed the date in the heading, but left the other verbiage there, and since the last meeting was cancelled, it still says cancelled. | 17:20 |
| SlickNik | Let me update that. | 17:20 |
| amrith | let there be light, and SlickNik appeared. | 17:23 |
| *** robertmyers has joined #openstack-trove | 17:23 | |
| SlickNik | Updated. | 17:27 |
| SlickNik | If folks aren't around to discuss their item at the BP meeting because of the confusion, we can just move that item to next week's meeting. | 17:29 |
| *** jasonb365 has quit IRC | 17:30 | |
| *** nexusz99 has joined #openstack-trove | 17:40 | |
| *** harlowja_away is now known as harlowja | 17:41 | |
| *** boblebauce has quit IRC | 17:46 | |
| *** annashen has joined #openstack-trove | 17:49 | |
| *** Riddhi has joined #openstack-trove | 17:52 | |
| *** romainh has quit IRC | 18:00 | |
| SlickNik | #startmeeting trove-bp-meeting | 18:01 |
| openstack | Meeting started Mon Nov 17 18:01:10 2014 UTC and is due to finish in 60 minutes. The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:01 |
| openstack | The meeting name has been set to 'trove_bp_meeting' | 18:01 |
| SlickNik | Giving folks a few minutes to trickle in | 18:01 |
| SlickNik | Agenda at | 18:01 |
| grapex | o/ | 18:01 |
| SlickNik | #link https://wiki.openstack.org/wiki/Meetings/TroveBPMeeting | 18:01 |
| amrith | ./ | 18:01 |
| georgelorch | o/ | 18:02 |
| *** mattgriffin has quit IRC | 18:03 | |
| Riddhi | o/ | 18:03 |
| SlickNik | #topic Add support for DB2 Express-C datastore | 18:03 |
| *** arborism has joined #openstack-trove | 18:03 | |
| *** arborism is now known as amcrn | 18:03 | |
| amrith | this is johnma's BP. | 18:03 |
| SlickNik | #link https://review.openstack.org/#/c/133856/ | 18:03 |
| johnma | sorry I thought the meeting was at 1 | 18:04 |
| johnma | I am here | 18:04 |
| amrith | it is at 1 ; | 18:04 |
| amrith | ;) | 18:04 |
| amrith | 1 o'clock somewhere. | 18:04 |
| johnma | I was trying to add some more details to the bp but I will do that after this meeting I guess and include the feeedback | 18:04 |
| SlickNik | johnma: the meeting is at 18:00 UTC. | 18:05 |
| johnma | yes I get confused all the time. Sorry about that. Thanks SlickNik | 18:05 |
| SlickNik | Not a problem :) | 18:05 |
| amcrn | o/ | 18:05 |
| johnma | so this bp is to add support for DB2-Express C edition | 18:06 |
| johnma | so the idea is to support the default OS for this first version - ubuntu and fedora | 18:06 |
| johnma | and support the following guest api's: - launch , reboot, terminate, backup, restore, resize | 18:07 |
| johnma | there wont be any clustering or replication support in this version since its the Express-C edition | 18:08 |
| grapex | johnma: How close is using DB2-Express C to MySQL? Would you say its a close to it as is Percona and Maria? | 18:08 |
| johnma | the way we create users and grant provileges are very different | 18:09 |
| *** mattgriffin has joined #openstack-trove | 18:09 | |
| johnma | between DB2 and MySQL. for one there is no notion of a DB2 user. for creating user, we have to first create an OS user and then DB2 privileges to it | 18:10 |
| *** topshare has quit IRC | 18:10 | |
| SlickNik | johnma: Another question I had was around obtaining packages for DB2-Express C? Are they freely available on an apt-server somewhere? What is the redist license? | 18:11 |
| johnma | and there isnt a single table like MySQL where we can access and get the privileges for a user. | 18:11 |
| johnma | yes thats very good question SlickNik and one reason why I need to update the spec about the Kilo-1 milestone which I dont think we will make for this reason | 18:11 |
| johnma | this DB2 version is the free version, so there isnt any problem in that front. The problem area is that there is a registration process that user needs to go through first to get the packages | 18:12 |
| johnma | the registration process is free but I have been told that its there to prevent users from embargoed countries from downloading the packages | 18:13 |
| johnma | so we need to figure out a way to work around the registration process. We developed a prototype for the DB2 plugin with most of the features I mentioned above - (we need to implement the resize and backups apis's) which is why I thought we could make the Kilo-1 milestone | 18:14 |
| johnma | but we need to find a work around for the registration process | 18:14 |
| *** denis_makogon has quit IRC | 18:14 | |
| SlickNik | Okay, all of that is good information to put in the specs (once it's figured out). | 18:15 |
| amcrn | johnma: it looks like features such as replication require a yearly subscription? | 18:15 |
| johnma | sure will do that SlickNik | 18:15 |
| amcrn | is that restricted by license or by package? | 18:15 |
| *** thedodd has quit IRC | 18:16 | |
| johnma | amcrn: Express-C version doesnt support high availability which is why we arent going to implement replication , clustering features for this version. Like you said for those features , user will require a subscription | 18:16 |
| johnma | by license I believe | 18:17 |
| openstackgerrit | Merged openstack/trove-specs: Add requirement for APIImpact flag https://review.openstack.org/132346 | 18:17 |
| *** denis_makogon has joined #openstack-trove | 18:17 | |
| *** topshare has joined #openstack-trove | 18:17 | |
| johnma | as far as integration tests, what kind of tests do we usually run? | 18:19 |
| johnma | I have only included unit tests in there | 18:19 |
| SlickNik | johnma: Tests to test pretty much all the functionality that the datastore offers. | 18:20 |
| johnma | ok | 18:20 |
| SlickNik | So in this case, that would be provisioning, and backup and restore. | 18:20 |
| johnma | sure, sounds good. thanks SlickNik | 18:21 |
| SlickNik | One thing I'm working through is how we can leverage an external CI system for third party tests, and what those requirements look like for additional datastores. | 18:21 |
| SlickNik | So I'll keep you in the loop with that info. | 18:22 |
| johnma | yes, that would be great. Appreciate it. | 18:22 |
| SlickNik | Thanks johnma! | 18:22 |
| SlickNik | Any other questions? | 18:22 |
| johnma | I am good on this | 18:23 |
| SlickNik | #topic Add support for Apache CouchDB datastore | 18:23 |
| johnma | yes thats me again | 18:23 |
| SlickNik | #link https://review.openstack.org/#/c/133849/ | 18:23 |
| SlickNik | Pretty much the same discussion applies here as well. | 18:23 |
| johnma | so this is to add support for another datastore - Apache CouchDB | 18:24 |
| johnma | thats right | 18:24 |
| johnma | again for this , we are planning to support the following guest agent api's: - launch | 18:24 |
| johnma | - reboot | 18:24 |
| johnma | - terminate | 18:24 |
| johnma | - resize | 18:24 |
| johnma | - backup | 18:24 |
| johnma | - restore | 18:24 |
| johnma | - replication | 18:24 |
| johnma | couchdb does backups through their replication interface. So they dont have an explicit backup solution. | 18:25 |
| johnma | One question I had is , is there any reason why the other no-sql datastores dont support managing databases and users (create/list/delete | 18:26 |
| johnma | ) | 18:26 |
| grapex | johnma: There's feeling it isn't necessary. Those API calls are actually viewed as an extension to Trove rather than a core feature. | 18:27 |
| johnma | again the plan is to support CouchDB on ubuntu and fedora for this release | 18:27 |
| amrith | johnma would you like to support them for CouchDB? | 18:27 |
| *** topshare has quit IRC | 18:27 | |
| SlickNik | johnma: Because the implementations chose not to implement that extension. Frankly folks felt it wasn't absolutely necessary, and the users extension has always been somewhat controversial. | 18:28 |
| johnma | I was thinking of implementing those. Again the product team hasnt mandated that. I might have to get back with them and see what their use case is | 18:29 |
| johnma | to be honest I havent gotten that far as to prototyping that so I dont know how much work is going to be involved to implement it | 18:30 |
| SlickNik | johnma: I'd recommend an initial spec without them, which you can revisit later as part of another spec if you feel that it's really needed. | 18:30 |
| SlickNik | since it's an extension, it should be easy to separate out. | 18:31 |
| johnma | sounds good. i will take your advice SlickNik | 18:31 |
| johnma | Thats all I had. Any questions or concerns I can address? | 18:32 |
| johnma | We are planning for clustering work for the next release so wont be doing clustering in this one | 18:33 |
| SlickNik | Sounds good, let's move on to the next item then. Thanks johnma! | 18:33 |
| SlickNik | #topic Example Snippet Generator | 18:34 |
| johnma | Thank you. Appreciate all the feedback | 18:34 |
| SlickNik | Hey there, grapex | 18:34 |
| grapex | Yo everyone. If anyone isn't familiar with the Trove API docs, they have these snippets showing what the content of the REST request and response is | 18:35 |
| grapex | For example, here's on on "configurations" | 18:35 |
| grapex | https://github.com/openstack/trove/blob/master/apidocs/src/samples/db-configuration-create-request-json.txt | 18:35 |
| grapex | https://github.com/openstack/trove/blob/master/apidocs/src/samples/db-configuration-create-request.json | 18:35 |
| grapex | https://github.com/openstack/trove/blob/master/apidocs/src/samples/db-configuration-create-response-json.txt | 18:35 |
| grapex | These end up going into the PDFs that get generated on how to use the Trove API | 18:36 |
| grapex | the problem is, they're generated statically and could be nothing but lies | 18:36 |
| grapex | though to be fair they probably are mostly true ;) | 18:36 |
| grapex | So this blueprint adds a test which captures the request and response body of the python-troveclient we all know and (hopefully) love | 18:37 |
| grapex | the tests then does a diff to see if the files in the output of this test is different from the files in source control, and if it is the test fails | 18:38 |
| grapex | meaning | 18:38 |
| grapex | if someone inadvertently changes the API in some minor way that makes a documentation snippet inaccurate, the test fails | 18:38 |
| grapex | they have to update the actual text snippet file to be accurate as part of their pull request to make Jenkins pass | 18:38 |
| grapex | Hopefully that will then trigger a discussion during the code review process. | 18:38 |
| amcrn | grapex: this should definitely be helpful, nice work | 18:38 |
| grapex | So lets say, just to make up a fictional example, the configuration had some value in the request change from a number to string | 18:39 |
| cp16net | ^^ would have found some issues we've had to back port... | 18:39 |
| grapex | the test would fail | 18:39 |
| grapex | and the person who saw this would either change the code, so the snippet would be the same | 18:39 |
| grapex | or, if that change was intentional, they'd change the snippet. Core reviewers would see it and then decide if the API change was OK or not | 18:39 |
| *** rushiagr is now known as rushiagr_away | 18:40 | |
| grapex | the end | 18:40 |
| SlickNik | cp16net: I was gonna say — wish we had this earlier. | 18:40 |
| SlickNik | grapex: Nice! This was the same thing that we discussed at the mid-cycle meetup, right? | 18:40 |
| cp16net | :-P | 18:40 |
| grapex | SlickNik: Yep. And the same thing that was discussed during the Sprint midcycle in Austin- this is actually one big motivation for the Trove docs living in the Trove repo. | 18:40 |
| SlickNik | Just in more concrete form. | 18:40 |
| grapex | Hopefully it will also get us in the habit of writing docs as we add features | 18:41 |
| grapex | I've noticed in a lot of code reviews recently, there is push back if some minor nitpick doesn't match what the blueprint said | 18:41 |
| grapex | I might be starting a tangent here | 18:41 |
| grapex | but I don't agree with that | 18:41 |
| amcrn | lol | 18:41 |
| amrith | write a blueprint about it ;) | 18:41 |
| grapex | The blueprint is to get people on board with the gist of the change, make sure people don't outright hate it and generally agree the idea is sound | 18:41 |
| grapex | The documentations is where we should actually... documentate what the API does | 18:42 |
| openstackgerrit | Merged openstack/trove-specs: Add RSS feed https://review.openstack.org/131253 | 18:42 |
| grapex | I can't see users reading the specs repo for behavior | 18:42 |
| amcrn | the nitpicking is a bit tangential, but i agree that this will definitely be a boon for users wanting to understand the req/resp model | 18:43 |
| amcrn | vs. waiting for labeleled releases with new doc cuts | 18:43 |
| grapex | As work is done, the right thing to do might not be what the blueprint said. I'd like to endorse that as it encourages people to think about edge cases not present in the plain text description of what they thought they would be writing. | 18:43 |
| grapex | amcrn: Agreed | 18:43 |
| grapex | And the blueprint doesn't cover this- | 18:44 |
| grapex | but I've always thought it would be cool to somehow show an example of what the Python code involved to make things happen using the python-trovelcient alongside the generic REST information. | 18:44 |
| grapex | That's probably a bit futuristic at this point, plus it could involve really changing the docs | 18:45 |
| grapex | anyway... thoughts? | 18:45 |
| SlickNik | I agree with you guys completely on this. | 18:45 |
| SlickNik | The spec won't be able to cover 100% of the cases anyhow. | 18:46 |
| SlickNik | And having some latitude for design flexibility is a good thing. | 18:46 |
| openstackgerrit | amrith proposed openstack/trove: Rename generic variable named with mysql specific name https://review.openstack.org/129528 | 18:46 |
| SlickNik | But let's try not to get too derailed with this topic in the interest of time for this meeting. :) | 18:46 |
| cp16net | +1 to the doc changes. | 18:46 |
| SlickNik | Okay, any other questions for this? | 18:47 |
| Riddhi | +1 from my side as well | 18:47 |
| SlickNik | #topic Flavors per datastore | 18:48 |
| SlickNik | #link https://blueprints.launchpad.net/trove/+spec/associate-flavors-datastores | 18:48 |
| SlickNik | So this spec was previously approved for Juno. | 18:48 |
| SlickNik | But didn't make it in time after the Feature Freeze IIRC. | 18:48 |
| Riddhi | sgotliv and peterstac had some concerns about the api changes | 18:49 |
| Riddhi | thought we could discuss about it in the meeting and get some consensus | 18:49 |
| amcrn | i've got some concerns too, but i'll yield the floor to sgotliv + peterstac first | 18:49 |
| amrith | neither of them appears to be here | 18:50 |
| amrith | amcrn, why don't you go ahead | 18:50 |
| amrith | I'll try and rustle them up | 18:50 |
| Riddhi | amcrn: yeah...go ahead :) | 18:50 |
| peterstac | gotta page it back into memory first ;) | 18:50 |
| amcrn | i haven't had a chance to peer into the code review, but is https://wiki.openstack.org/wiki/Trove/associate-flavors-datastores still up-to-date? if so, my concern is with the default-datastore behavior. | 18:51 |
| Riddhi | peterstac: your comment on this review might help - https://review.openstack.org/#/c/109824/ | 18:51 |
| Riddhi | amcrn: yes it is up to date | 18:51 |
| amcrn | default_datastore was only introduced to avoid breaking backwards compatibility for those who had deployments that relied on mysql being the only datastore in existence, aka pre icehouse | 18:52 |
| peterstac | amcrn: I think that was my concern - if there were no flavors defined, then it looked like it would fail | 18:52 |
| amcrn | generally speaking, any new deployment should not set that value | 18:52 |
| Riddhi | peterstac's comments were - "I have to run the code to be sure, but from my review it looks like this becomes a required feature. Not sure that's what existing customers would want. If it turns out I'm mistaken - or the consensus is that that's what we want, I'll switch my vote (of course)." | 18:52 |
| Riddhi | peterstac, amcrn: if there are no flavors associated to the datastore version..the default flavors are listed | 18:53 |
| peterstac | Unfortunately my env got upside down so I haven't had a chance to run the code yet | 18:53 |
| amcrn | in short, i'd like to remove the default flavor listing route | 18:53 |
| amcrn | it's an unnecessary shortcut for a cfgopt that shouldn't be used | 18:53 |
| amrith | Riddhi, your most recent comment appears to contradict your response in code review (patch set 9) "The expected behavior is to check if the flavor that is to be used for the instance, has a binding with the datastore_version.id being used for the instance. It throws an exception if not. The code tries to check the same." | 18:53 |
| *** thedodd has joined #openstack-trove | 18:55 | |
| Riddhi | okay..one at a time: amcrn: you do not want the list default flavors api call anymore you say? | 18:55 |
| amcrn | pretty much. rip out GET /{tenant_id}/flavors and i'm ok with the proposal. | 18:55 |
| amcrn | actually, that isn't a proposal, that route already exists... | 18:56 |
| *** johnma has quit IRC | 18:56 | |
| SlickNik | Wouldn't that be altering the API though? | 18:56 |
| amcrn | so if a deployer doesn't have default_datastore set, that behavior has to remain as it is today | 18:56 |
| grapex | amcrn: Wait, I'm confused. I thought you just wanted it so that if a datastore wasn't specified then it would show *all* flavors, rather than the default. Right? | 18:56 |
| amrith | sorry, what? amcrn are you suggesting deleting /{tenant_id}/flavors? | 18:56 |
| amcrn | SlickNik: i'm backpedalling | 18:56 |
| edmondk | you would need to version the API if you ripped out the default /flavors that currently exists | 18:56 |
| amcrn | no the blueprint doesn't state whether the routes are new or changed | 18:56 |
| amcrn | yes yes yes | 18:56 |
| amcrn | hence the confusion at first | 18:57 |
| grapex | amrith: It's hard to get context on your last comment. Maybe we should just start over and people who are still not ok with this can state what they want? | 18:57 |
| grapex | Let's go with amcrn first | 18:57 |
| amcrn | i rescind my comments, because we can't touch GET /{tenant_id}/flavors due to backwards compatibility, it doesn't matter how nonsensical it is | 18:58 |
| SlickNik | Ah got it — took me a moment to realize it was an existing route as well. | 18:58 |
| amrith | amrith, I'm all set (see amcrn's most recent comment) | 18:58 |
| grapex | Uh-oh, I think someone has hacked into amrith's account and just inadvertently referenced him in the third person! | 18:58 |
| amrith | I talk to myself all the time (in first person). it is boring. | 18:59 |
| edmondk | Just to clarify is the existing /{tenant_id}/flavors remaining exactly the same as it is now? | 18:59 |
| grapex | amrith: Tim knows what you mean. | 18:59 |
| grapex | edmondk: I think so, right Riddhi? | 18:59 |
| Riddhi | amcrn, SlickNik: yes, it is an existing route..the only reason it was outlined in the bp was to maintain the backward compatibility...i think the desc for the /flavors api call is causing the confusion.. | 18:59 |
| peterstac | edmondk: Yes, that's an existing API call | 18:59 |
| edmondk | got it | 19:00 |
| peterstac | Isn't the new one: GET /{tenant_id}/flavors/{datastore_version_id} ? | 19:00 |
| grapex | Riddhi: By pointing out you wouldn't change a feature that was so broadly despised, you actually made everyone think you were changing the API. :) | 19:00 |
| Riddhi | peterstac: yes..thats the new one | 19:00 |
| SlickNik | edmondk: I think it's a subtle change — previously you'd get all flavors, after this change you'd presumably get all flavors associated with the default datastore. | 19:00 |
| amrith | #idea ... take existing BP and make it an RST and let people comment on it. | 19:00 |
| Riddhi | SlickNik: yes thats right | 19:00 |
| peterstac | SlickNik: yeah, that would be bad | 19:00 |
| Riddhi | the new call is /{tenant_id}/flavors/{datastore_version_id} | 19:01 |
| grapex | amrith: I'd normally say yes... but I'd really like to just finish getting to the bottom of these concerns | 19:01 |
| Riddhi | the trove-manage utility provides the ability to add/delete flavors | 19:01 |
| grapex | amrith: only due to the extreme age of this blueprint. | 19:01 |
| amrith | grapex, I'm proposing it because we are discussing here (in IRC) things that would be better (IMHO) to discuss in review. | 19:01 |
| Riddhi | associated with these ds versions | 19:01 |
| *** jmontemayor has quit IRC | 19:01 | |
| amrith | but I see your point about the age of this BP | 19:02 |
| Riddhi | the old flavors route/call still remains the same | 19:02 |
| amrith | it may not survive the replanting | 19:02 |
| SlickNik | amrith / grapex: I'd like to get an .rst in for spec bookkeeping for kilo though. | 19:02 |
| grapex | SlickNik: Argh | 19:02 |
| SlickNik | Even if it's just the current wiki page replanted to rst format. | 19:02 |
| grapex | SlickNik: That *is* a good reason though | 19:02 |
| *** jmontemayor has joined #openstack-trove | 19:02 | |
| grapex | Still | 19:03 |
| grapex | I feel like I don't understand people's concerns | 19:03 |
| amrith | grapex, I'll do the gardening if it will help ease the workload | 19:03 |
| amcrn | Riddhi: make sure to make the id a string and not an integer | 19:03 |
| amrith | grapex, ask Tim about it ;) | 19:03 |
| Riddhi | amcrn: you mean the flavor id right? | 19:04 |
| * grapex wonders if he'll go to hell if he also asks Riddhi to write documentation snippets for this... | 19:04 | |
| amcrn | correct | 19:04 |
| Riddhi | grapex: will do! | 19:04 |
| amcrn | otherwise the id_str hack will have to propigate to a newly introduced api, which would be sad | 19:04 |
| grapex | Riddhi: You are *really* bad at bargaining! | 19:04 |
| SlickNik | Thanks Riddhi! Really really appreciate it. | 19:04 |
| grapex | The two big concerns right now are from amcrn and amrith right? | 19:05 |
| SlickNik | Okay, we're done with meeting. We can stay back to close on rst / spec conversation as needed. | 19:05 |
| SlickNik | Thanks all! | 19:05 |
| SlickNik | #endmeeting | 19:05 |
| openstack | Meeting ended Mon Nov 17 19:05:28 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:05 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/trove_bp_meeting/2014/trove_bp_meeting.2014-11-17-18.01.html | 19:05 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/trove_bp_meeting/2014/trove_bp_meeting.2014-11-17-18.01.txt | 19:05 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/trove_bp_meeting/2014/trove_bp_meeting.2014-11-17-18.01.log.html | 19:05 |
| *** vigneshvar_ has joined #openstack-trove | 19:06 | |
| SlickNik | grapex: I don't think they're concerns as such, but more of implementation caveats. | 19:07 |
| SlickNik | At least the "string" for ID one that amcrn mentions is. | 19:08 |
| grapex | SlickNik: Ok | 19:08 |
| grapex | SlickNik: Btw- I have no idea why this is failing: https://review.openstack.org/#/c/132367/ | 19:09 |
| grapex | AssertionError: fake_host_1 != fake_host_2 | 19:09 |
| amcrn | grapex: yeah, i have no concerns now that the default route confusion was cleared up. | 19:09 |
| grapex | amcrn: Ah, good to know | 19:10 |
| *** vigneshvar has quit IRC | 19:10 | |
| grapex | I think the big problem with this blueprint is its been passed around to three people. I hate that Riddhi now has to write the spec but it will probably eliminate some confusion about it. | 19:10 |
| grapex | SlickNik: Back to the example generator pull request: Is this error about the fake host name not matching a random error people are normally seeing? | 19:11 |
| Riddhi | grapex: yeah..makes sense..! | 19:11 |
| SlickNik | grapex: not sure — trying to make sense of the traceback. | 19:12 |
| grapex | SlickNik: fake_host_2 != fake_host_1 | 19:13 |
| grapex | This was never a very reliable test... | 19:13 |
| amcrn | Riddhi: fwiw, i edited https://wiki.openstack.org/wiki/Trove/associate-flavors-datastores to differentiate between new routes and existing routes. | 19:14 |
| grapex | Actually, its running the snippets... thats not good | 19:14 |
| Riddhi | amcrn: saw that..thank you..was just about to do it myself:D | 19:14 |
| amcrn | :) | 19:14 |
| grapex | Ok... I guess this is a test that only runs one way on one host OS and different somewhere else | 19:14 |
| grapex | I'll figure it out, n/m | 19:14 |
| SlickNik | grapex: It looks like it's expecting an ordered listing from the API, which might not be the case since the hosts can be returned in any order by the API. | 19:15 |
| grapex | SlickNik: Yeah, I noticed it right after I spoke up | 19:15 |
| grapex | If you want to see your dumbest mistakes, just ask someone else for assistance. :) | 19:16 |
| SlickNik | Oh I definitely know all about that. :) | 19:16 |
| *** jmontemayor has quit IRC | 19:19 | |
| amcrn | grapex: i'll mail you a rubber duck (http://en.wikipedia.org/wiki/Rubber_duck_debugging) ;) | 19:23 |
| *** jmontemayor has joined #openstack-trove | 19:25 | |
| grapex | amcrn: Oh awesome. I'm worried though that that might create jealousy with my split personality Jim. | 19:46 |
| amcrn | haha | 19:47 |
| grapex | I think if I used that thing eventually I'd hear the duck talking to me in Mr. Hat's voice... "The tests failed again, didn't they? Do you even *KNOW* how to write Python!" | 19:47 |
| grapex | The midday quiet of the office would be shattered by me yelling "Shut up you stupid duck!" | 19:48 |
| openstackgerrit | Tim Simpson proposed openstack/trove: Create example generator https://review.openstack.org/132367 | 19:51 |
| *** jmontemayor has quit IRC | 19:59 | |
| *** jmontemayor has joined #openstack-trove | 20:04 | |
| *** sgotliv has joined #openstack-trove | 20:14 | |
| *** sgotliv has joined #openstack-trove | 20:14 | |
| *** todd_dsm has joined #openstack-trove | 20:19 | |
| *** boblebauce has joined #openstack-trove | 20:19 | |
| amrith | denis_makogon, yt? | 20:22 |
| *** denis_makogon_ has joined #openstack-trove | 20:24 | |
| *** denis_makogon has quit IRC | 20:25 | |
| *** denis_makogon_ is now known as denis_makogon | 20:25 | |
| *** dmakogon_ has joined #openstack-trove | 20:25 | |
| denis_makogon | amcrn, ping | 20:27 |
| amrith | denis_makogon, ping | 20:27 |
| amrith | ;) | 20:28 |
| amrith | or you can talk to amcrn ;) | 20:28 |
| denis_makogon | amrith, sure, i'm in | 20:28 |
| denis_makogon | amrith, anything new my friend? | 20:28 |
| amrith | hey, had a good trip home? | 20:28 |
| amcrn | denis_makogon: hi | 20:36 |
| denis_makogon | amcrn, i want to talk about https://review.openstack.org/#/c/134583/ | 20:38 |
| amcrn | sure | 20:38 |
| denis_makogon | amcrn, there's a problem, if we don't do clubbing, we would have to make python-troveclient aware of supported datastores. | 20:40 |
| amcrn | denis_makogon: that's a foregone conclusion, isn't it? | 20:41 |
| *** sgotliv has quit IRC | 20:43 | |
| denis_makogon | amcrn, iirc no | 20:43 |
| amcrn | that point is somewhat tangential to the discussion at hand | 20:43 |
| amcrn | adding a node and adding a shard are two different things | 20:44 |
| denis_makogon | i agree | 20:44 |
| denis_makogon | but we have to dael with clients stateless | 20:44 |
| amrith | denis_makogon, didn't we discuss this in Paris? I recall that the issue was that we didn't like 'add_shard'. 'add_node' is fine if I recall correctly. | 20:44 |
| denis_makogon | amrith, sure we did | 20:45 |
| amcrn | i don't understand the "i don't like add_shard'. | 20:45 |
| denis_makogon | we also have some notes on etherpad | 20:45 |
| *** exploreshaifali has quit IRC | 20:45 | |
| amcrn | i've read the etherpad. the point is not clear. | 20:45 |
| amrith | my recollection was that add_node wuld remain and add_shard (the API) would exist for 1 release and in future people would have to use cluster_scaleup or some such. | 20:45 |
| amrith | I believe that we were just renaming the API | 20:45 |
| denis_makogon | amrith, correct | 20:45 |
| amcrn | i'll reiterate that adding a shard is a distinct action | 20:46 |
| amrith | like we didn't like "slave" in replication so we called it "replica" | 20:46 |
| amcrn | the concept of a shard doesn't exist in any other datastore | 20:46 |
| amrith | amcrn, the thought in Paris was that trove would support an action "scaleup". the implementation for mongoDB would be add_shard, and for some other datastore it would be something else. | 20:46 |
| amrith | I'm not saying that's right or wrong | 20:47 |
| amrith | just that this is what was discussed and "agreed" to. | 20:47 |
| amrith | the intent was to expose a datastore agnostic API | 20:47 |
| denis_makogon | i'd say that we need to have generic way (from clients API, or Web, or CLI) to execute upscaling against different clusters | 20:47 |
| amrith | with datastore specific implementations. | 20:47 |
| amcrn | the point is that datastores have eccentricities, aka actions, that are unique to them. intrinsically, these cannot be datastore-agnostic. | 20:48 |
| amrith | amcrn, agreed | 20:48 |
| amrith | however, the objective was to define terms that would definite datastore agnostic operations. | 20:48 |
| amrith | provision/deprovision, scaleout, scalein, scaleup, scaledown etc., | 20:48 |
| amcrn | so why would add_shard be deprecated? | 20:49 |
| amrith | scaleup and scaledown are our current resize operators | 20:49 |
| *** openstackgerrit has quit IRC | 20:49 | |
| *** openstackgerrit has joined #openstack-trove | 20:49 | |
| denis_makogon | amcrn, yes, right after Kilo + 1 release | 20:49 |
| amrith | amcrn the reason was that the api could be defined in terms of datastore agnostic operations. | 20:49 |
| amrith | add_shard is datastore specific | 20:49 |
| SlickNik | hey guys, just saw this conversation. | 20:49 |
| amcrn | i get the intent, i'm just stating it's not a reality | 20:49 |
| amrith | amcrn, why is not a reality? | 20:50 |
| amrith | the mongoDB implementation would be the existing add_shard code ... | 20:50 |
| SlickNik | amrith: I think what amcrn is saying is that you can define a scale up operation/API without having to deprecate the add-shard action for a mongo-db cluster. | 20:50 |
| amcrn | does scaleup add a shard or a node? | 20:50 |
| amcrn | that's why it doesn't work. | 20:50 |
| amrith | amcrn, that depends on the implementation | 20:50 |
| amcrn | so you introduce scaleup2? | 20:51 |
| amrith | no. | 20:51 |
| amrith | are you saying that there are multiple ways to scale up mongoDB? | 20:51 |
| amcrn | well, first, the term "scale" is a poor choice | 20:51 |
| amcrn | that aside | 20:51 |
| amrith | in that case we would like the api to be able to handle that. | 20:51 |
| amcrn | yes, you can add node(s) to a shard, and you can add shards. | 20:51 |
| amrith | so, if we adopt the thinking from Paris, then "scaleup" or whatever would need to be able to express both of those variants. | 20:52 |
| amcrn | with mongodb you need the ability to express votes, type (arbiter or member), hidden or not hidden, etc .etc. | 20:53 |
| denis_makogon | server side can handle any implementation of an action, but what about client side, if we'd still have multiple action how would client know which action to execute against given cluster ? | 20:53 |
| amcrn | you'll end up with an extremely bloated generic action that is nearly impossible to decipher | 20:53 |
| amrith | the converse is that we end up with an extremely bloated API with many unsupported calls. I believe that this is what we were trying to avoid. | 20:54 |
| amcrn | if by bloated you mean you have granular payloads that are specific to datastores, then yes. | 20:54 |
| amcrn | the original blueprint modeled this. each datastore typically needs 2-4 pieces of metadata when adding a node, which means your documentation for add_node will have 20+ fields, each littered with "this is only applicable to <x> datastore" | 20:55 |
| amrith | so maybe the action here is to look at the datastores we know of and make sure that a generic call (scaleXX) can be used for the various scenarios we expect to encounter. | 20:56 |
| denis_makogon | amcrn, could you please answer how should client know which action are allowed and which are not against cluster datastore? | 20:56 |
| amcrn | i'm not concerned about the cli at the moment. as long as the api is modeled correctly, the cli can adapt as deemed necessary. | 20:57 |
| denis_makogon | amcrn, what about web? | 20:57 |
| amrith | amcrn, yes to that. absolutely. getting the api right is more important. the CLI will be a breeze by comparison. | 20:58 |
| amcrn | amrith: depending on the datastore, building a node vs. adding a node vs. joining a node are different. the terminology used is paramount. | 20:58 |
| *** boblebauce has quit IRC | 20:58 | |
| amcrn | heck, even "node" vs. "member" mean different things depending on the datastore | 20:58 |
| amrith | absolutlely. a trivial solution that would meet the goal that we set out to acheive in paris would be to have the api's be /.../scaleup/add_shard and /.../scaleup/add_node | 20:59 |
| amrith | but that's not what I'm after. | 20:59 |
| SlickNik | amrith / amcrn: So just to confirm that folks are on the same page, the way we support actions today is through a single API endpoint <instance-uuid>/action. | 20:59 |
| SlickNik | The actual action to perform is part of the payload. | 20:59 |
| openstackgerrit | Bob Thyne proposed openstack/python-troveclient: Adds support for Keystone V3 API https://review.openstack.org/134126 | 20:59 |
| amcrn | SlickNik: correct | 21:00 |
| *** sgotliv has joined #openstack-trove | 21:00 | |
| amrith | yes, that's the intent of the earlier /scaleup/add_shard or scaleup/add_node approach | 21:00 |
| amrith | <instance-uuid>/scaleup/add_node wouldn't be outrageous | 21:00 |
| amrith | action ~ scale... | 21:00 |
| amcrn | so how would replacing a node be modeled? | 21:00 |
| amcrn | scale-nothing? | 21:01 |
| amrith | what's the datastore agnostic "action" for replacement? | 21:01 |
| amrith | <instance-uuid>/replace/... | 21:01 |
| SlickNik | amrith: But what if your datastore "scales up" not by adding a node, but by adding a shard? | 21:02 |
| amrith | SlickNik, that would be <instance-uuid>/scaleup/add_shard | 21:02 |
| amrith | if some other datastore does it by more hamsters, you may have | 21:03 |
| amcrn | but what have we solved then? it's not generic, because add_shard still exists | 21:03 |
| amcrn | you've just introduced another level of indirection (scaleup) | 21:03 |
| amrith | <instance-uuid>/scaleup/add_hamsters | 21:03 |
| amrith | amcrn, like I said this isn't really the idea way | 21:03 |
| *** vigneshvar_ has quit IRC | 21:03 | |
| amrith | I said (at 15:59) a trivial solution would be ... this is just a lame indirection | 21:03 |
| amrith | the right way is to come up with a proper set of abstractions that will be truly database/datastore agnostic. | 21:04 |
| amrith | "so maybe the action here is to look at the datastores we know of and make sure that a generic call (scaleXX) can be used for the various scenarios we expect to encounter." | 21:04 |
| amrith | that was my understanding of the rationale for this discussion in Paris. | 21:04 |
| amrith | SlickNik, is that right? | 21:04 |
| SlickNik | But in that case, don't you end up with a fragmented API? I.e. different datastores support only some parts of the API, and you're not quite sure which are supported for which datastores? | 21:05 |
| amcrn | i don't get the value of the abstraction. it merely guarantees that people who really understand their datastore won't get to use terms that they know and understand. | 21:05 |
| SlickNik | I think folks suggested that it might be useful to have something generic like grow-cluster. | 21:07 |
| amrith | SlickNik, that is true. it would be good to have a properly modeled generic abstraction. | 21:07 |
| amcrn | what does "grow-cluster" mean in the context of mongodb? how about redis w/ sentinel? | 21:07 |
| amcrn | it's not clear, so you have to keep adding datastore-specific fields to a "generic" action for it to make sense | 21:07 |
| amcrn | which defeats the original intent altogether | 21:08 |
| amrith | if we go down this path, and conclude that each datastore has its own eccentricities, then the abstraction I'd suggest is <instance-uuid>/mongodb/... | 21:08 |
| amrith | <instance-uuid>/redis/... | 21:08 |
| amrith | or some such | 21:08 |
| SlickNik | amcrn: the only way I see something like that make sense is if you'd be able to define as part of the datastore what a generic "grow" API call would mean. | 21:10 |
| amrith | in any event, the intent of the bp was to be to explore whether we could have such a "more generic" api. | 21:10 |
| amrith | SlickNik, I believe that is possible. | 21:10 |
| amrith | and would be beneficial. | 21:10 |
| amcrn | that's extremely difficult | 21:10 |
| *** thedodd has quit IRC | 21:10 | |
| SlickNik | And even then, I'm not sure if that could be solved, or if that might actually be a property of the deployment in some cases. | 21:11 |
| amrith | SlickNik, what do you suggest? | 21:12 |
| amrith | is it worth exploring some more or not? | 21:12 |
| amrith | I think we agreed in Paris that this was worthwhile and Denis wrote the spec. Are we now saying thank you but no thank you? | 21:13 |
| openstackgerrit | Peter Stachowski proposed openstack/trove: Mark certain configuration options as deprecated https://review.openstack.org/124846 | 21:13 |
| denis_makogon | so, let me clarify something, for now we have actions for clusters, but we as users don't know which actions are allowed (right?), what if we'd have an API that describes which cluster actions are allowed for execution against specific datastore? | 21:14 |
| SlickNik | amrith: For one, I think the spec that's written is not a reflection of what we are talking about here, and might be one of the main reasons for the -2 on the spec. | 21:14 |
| amcrn | denis_makogon: you're resurrecting the idea of "capabilities". be careful, dragons be here ;) | 21:14 |
| amrith | I thought that was what capabilities was for. | 21:14 |
| openstackgerrit | Peter Stachowski proposed openstack/trove: Mark certain configuration options as deprecated https://review.openstack.org/124846 | 21:14 |
| amrith | damn, amcrn beat me to it as I read what SlickNik wrote ;) | 21:15 |
| SlickNik | amrith: specifically the topic of deprecating the "add-shard" action | 21:15 |
| SlickNik | But yes, I'm not sure we want to go down a capabilities route either. | 21:15 |
| amrith | SlickNik, yes, there's some difference between what we discussed and what is in the spec. but looking only at what we discussed, (which did include deprecating add-shard), what are we saying? | 21:15 |
| *** boblebauce has joined #openstack-trove | 21:16 | |
| amrith | if we don't deprecate add-shard then adding "grow-cluster" seems pointless. | 21:16 |
| amrith | because tomorrow, you'll need "add-hamster" as well | 21:16 |
| amrith | and "expand-redis-with-sentinel" | 21:16 |
| amrith | and so on. | 21:16 |
| denis_makogon | amrith, agreed | 21:17 |
| SlickNik | amrith: I'm not sure I buy that. | 21:17 |
| amcrn | fwiw, when this was originally discussed, there was a consensus that having (1) /action/<the_action> and (2) /<datastore>/action were more harmful than (3) /action with payloads varying on the datastore/situation. | 21:18 |
| amrith | SlickNik, why? | 21:18 |
| SlickNik | As a user of the trove API, do I really care if I grow my cluster by adding a shard, or by adding a hamster? | 21:18 |
| amrith | amcrn, yes, that is what we talked about. | 21:18 |
| amrith | SlickNik, if your datastore has two distinct capabilities, I believe you would | 21:19 |
| amrith | like the ability to choose the right one for you. | 21:19 |
| denis_makogon | SlickNik, amrith is right | 21:19 |
| amrith | given the particular reason why you are "growing the cluster". | 21:19 |
| amrith | if you have more data with the same keys, you'd like to grow the shard. | 21:19 |
| SlickNik | In that case your generic API would not work, since you can now not differentiate whether to add a shard or a hampster just depending on that one API call. | 21:19 |
| amrith | if you have more data and want to spread it around, you'd want to add shards. | 21:20 |
| amrith | SlickNik, the payload to the generic api would tell which you wanted. | 21:20 |
| amrith | that would be like (3) in amcrn's outline | 21:20 |
| amrith | the issue is what we define as the action | 21:20 |
| amrith | is it "grow cluster" or "add shard" | 21:21 |
| amrith | is "add shard" in the payload | 21:21 |
| amrith | or the action | 21:21 |
| amrith | I thought we wanted "grow cluster" to be the action | 21:21 |
| amrith | and "add shard" the payload | 21:21 |
| amrith | which make deprecating "add shard" make sense | 21:21 |
| SlickNik | If you're depending on the payload to grow cluster, how is that different from depending on the payload to /action? | 21:21 |
| amrith | and my thinking at the time was the simplistic indirection we discsussed arlier. | 21:21 |
| *** fifieldt_ has joined #openstack-trove | 21:22 | |
| amrith | the distinction is that you have 1 action with two kinds of payload. or two actions (each with their own payload). | 21:22 |
| amrith | I thought we wanted 1 action | 21:23 |
| amrith | and would pay the price of having two kinds of payload | 21:23 |
| amrith | but I don't think we talked about the latter part | 21:23 |
| amrith | only the former, of having 1 action, the unified "grow cluster" action | 21:23 |
| *** fifieldt has quit IRC | 21:23 | |
| amrith | the distinction of add_node vs. add_shard is not something we discussed. | 21:23 |
| *** thedodd has joined #openstack-trove | 21:24 | |
| SlickNik | So don't we just get that if we add another payload like "add-node" to /action for clusters? | 21:24 |
| amrith | we certainly could. | 21:25 |
| SlickNik | does moving that payload to /grow-cluster instead give us much benefit other than pointing out that some of the actions you're now calling help grow the cluster? | 21:25 |
| amrith | good question, I don't know the answer for sure. | 21:26 |
| amrith | but at first blush it appears that it provides no more. | 21:27 |
| *** radez is now known as radez_g0n3 | 21:27 | |
| amrith | which of course begs the question, why not stick with what we have? | 21:27 |
| amrith | "add-shard" seems fine to me in that case. | 21:27 |
| amrith | anyway, toodles for now. I have to and play in traffic for a while. | 21:28 |
| denis_makogon | hm, good question | 21:28 |
| SlickNik | amrith: will catch up with you later. | 21:28 |
| SlickNik | amrith / amcrn / denis_makogon: thanks for bringing this up for discussion. | 21:29 |
| amcrn | word | 21:29 |
| *** miqui has quit IRC | 21:29 | |
| *** jcru has quit IRC | 21:29 | |
| *** exploreshaifali has joined #openstack-trove | 21:30 | |
| *** amrith is now known as _amrith_ | 21:37 | |
| *** sriram_tesora has quit IRC | 21:44 | |
| *** sriram_tesora has joined #openstack-trove | 21:44 | |
| *** jmontemayor has quit IRC | 21:51 | |
| *** tomblank has quit IRC | 22:01 | |
| *** jmontemayor has joined #openstack-trove | 22:05 | |
| *** grapex has quit IRC | 22:07 | |
| *** grapex has joined #openstack-trove | 22:08 | |
| *** grapex has quit IRC | 22:13 | |
| *** boblebauce has quit IRC | 22:18 | |
| *** exploreshaifali has quit IRC | 22:20 | |
| *** newb has quit IRC | 22:23 | |
| *** jmontemayor has quit IRC | 22:26 | |
| *** robertmyers has quit IRC | 22:27 | |
| *** tomblank has joined #openstack-trove | 23:06 | |
| *** vkmc has quit IRC | 23:11 | |
| *** sriram_tesora has quit IRC | 23:27 | |
| openstackgerrit | Riddhi Shah proposed openstack/trove-specs: Specs for flavors per datastore https://review.openstack.org/135128 | 23:52 |
| *** mattgriffin has quit IRC | 23:52 | |
| openstackgerrit | Riddhi Shah proposed openstack/trove-specs: Specs for flavors per datastore https://review.openstack.org/135128 | 23:53 |
| *** denis_makogon has quit IRC | 23:54 | |
| openstackgerrit | Riddhi Shah proposed openstack/trove-specs: Specs for flavors per datastore https://review.openstack.org/135128 | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!