| *** openstack has joined #openstack-trove | 00:02 | |
| *** jcru has quit IRC | 00:04 | |
| *** jcooley_ has quit IRC | 00:08 | |
| *** jcooley_ has joined #openstack-trove | 00:09 | |
| *** jmontemayor has quit IRC | 00:12 | |
| *** Barker has quit IRC | 00:12 | |
| *** datsun180b has quit IRC | 00:15 | |
| *** jcooley_ has quit IRC | 00:16 | |
| *** esp has joined #openstack-trove | 00:20 | |
| *** amytron has quit IRC | 00:23 | |
| *** matsuhashi has joined #openstack-trove | 00:27 | |
| *** jcooley_ has joined #openstack-trove | 00:48 | |
| *** michael-yu has quit IRC | 00:52 | |
| *** jcooley_ has quit IRC | 00:54 | |
| *** Barker has joined #openstack-trove | 00:56 | |
| *** Barker has quit IRC | 00:59 | |
| *** ViswaV has quit IRC | 01:02 | |
| *** yogesh has joined #openstack-trove | 01:07 | |
| *** michael-yu has joined #openstack-trove | 01:09 | |
| *** yidclare has quit IRC | 01:18 | |
| *** esp has left #openstack-trove | 01:19 | |
| vipul | cp16net: yea i'm going to submit a fix soon | 01:20 |
|---|---|---|
| *** ashestakov has joined #openstack-trove | 01:27 | |
| *** Ranjitha has quit IRC | 01:32 | |
| *** nosnos has joined #openstack-trove | 01:36 | |
| *** ashestakov has quit IRC | 01:36 | |
| *** michael-yu has quit IRC | 01:36 | |
| *** yogesh has quit IRC | 01:39 | |
| *** demorris has quit IRC | 01:42 | |
| *** jcooley_ has joined #openstack-trove | 01:42 | |
| *** jcooley_ has quit IRC | 01:48 | |
| *** Barker has joined #openstack-trove | 01:54 | |
| *** michael-yu has joined #openstack-trove | 01:59 | |
| *** amcrn has quit IRC | 02:01 | |
| *** michael-yu has quit IRC | 02:02 | |
| *** SnowDust has joined #openstack-trove | 02:17 | |
| *** grapex has quit IRC | 02:22 | |
| *** jcooley_ has joined #openstack-trove | 02:36 | |
| *** khyati has quit IRC | 02:36 | |
| *** jcooley_ has quit IRC | 02:42 | |
| *** erkules_ has joined #openstack-trove | 02:45 | |
| *** erkules has quit IRC | 02:46 | |
| *** rnirmal has quit IRC | 02:51 | |
| SlickNik | Looks like we have an issue with python-troveclient and the newly introduced PyPy gate tests. | 03:04 |
| SlickNik | We're using lxml which is a C library and it barfs when called from PyPy | 03:05 |
| SlickNik | https://gist.github.com/anonymous/98ce41fc2f4b2dd50d57 | 03:05 |
| SlickNik | considering that we're planning to move away from XML, I don't want to spend time moving to the stdlib compatible etree library. | 03:06 |
| SlickNik | I'm going to make the PyPy job non-voting for a bit. And we can turn it back when we pull out the xml dependencies. | 03:07 |
| SlickNik | ^^hub_cap | 03:07 |
| *** matsuhashi has quit IRC | 03:13 | |
| *** matsuhashi has joined #openstack-trove | 03:14 | |
| *** rwsu has quit IRC | 03:18 | |
| SnowDust | thanks SlickNik | 03:19 |
| SnowDust | that answers the import error for xml | 03:20 |
| SnowDust | in jenkins gate | 03:20 |
| *** SnowDust has quit IRC | 03:24 | |
| hub_cap | ++ SlickNik, lets nuke xml in the client _now_ and we can do it in the server side code in ~2 wks | 03:30 |
| *** michael-yu has joined #openstack-trove | 03:34 | |
| *** michael-yu has quit IRC | 03:39 | |
| openstackgerrit | A change was merged to openstack/python-troveclient: Update to the latest code from Oslo https://review.openstack.org/64439 | 03:39 |
| *** michael-yu has joined #openstack-trove | 03:46 | |
| *** matsuhashi has quit IRC | 03:49 | |
| *** jcooley_ has joined #openstack-trove | 03:57 | |
| *** harlowja is now known as harlowja_away | 04:01 | |
| *** jcooley_ has quit IRC | 04:02 | |
| *** michael-yu has quit IRC | 04:05 | |
| *** khyati has joined #openstack-trove | 04:06 | |
| *** harlowja_away is now known as harlowja | 04:06 | |
| *** michael-yu has joined #openstack-trove | 04:14 | |
| *** michael-yu has quit IRC | 04:16 | |
| *** Barker has quit IRC | 04:17 | |
| *** jcooley_ has joined #openstack-trove | 04:28 | |
| *** jcooley_ has quit IRC | 04:30 | |
| *** demorris has joined #openstack-trove | 04:31 | |
| *** parstac_pete has quit IRC | 04:33 | |
| *** parstac_pete has joined #openstack-trove | 04:35 | |
| *** amytron has joined #openstack-trove | 04:38 | |
| *** igor has joined #openstack-trove | 04:42 | |
| *** haomaiwang has quit IRC | 04:43 | |
| *** haomaiwang has joined #openstack-trove | 04:44 | |
| *** igor__ has quit IRC | 04:45 | |
| *** matsuhashi has joined #openstack-trove | 04:45 | |
| openstackgerrit | Vipul Sabhaya proposed a change to openstack/trove: Fix default_datastore migration script https://review.openstack.org/69537 | 04:52 |
| *** demorris has quit IRC | 04:56 | |
| *** haomaiwa_ has joined #openstack-trove | 04:56 | |
| *** michael-yu has joined #openstack-trove | 04:57 | |
| *** haomaiwang has quit IRC | 05:00 | |
| *** demorris has joined #openstack-trove | 05:03 | |
| *** SushilKM has joined #openstack-trove | 05:06 | |
| *** jcooley_ has joined #openstack-trove | 05:06 | |
| *** jcooley_ has quit IRC | 05:07 | |
| *** michael-yu has quit IRC | 05:08 | |
| cp16net | vipul: you there? | 05:28 |
| cp16net | vipul: good work but there was something thats changed that you didnt catch. i commented on it. thx | 05:32 |
| demorris | cp16net: nice work on the config edits | 05:42 |
| demorris | almost there! | 05:42 |
| *** yogesh has joined #openstack-trove | 05:48 | |
| *** demorris has quit IRC | 05:52 | |
| *** ashestakov has joined #openstack-trove | 05:53 | |
| *** ashestakov has quit IRC | 05:58 | |
| *** grapex has joined #openstack-trove | 06:09 | |
| *** grapex has joined #openstack-trove | 06:10 | |
| *** harlowja is now known as harlowja_away | 06:10 | |
| *** SnowDust has joined #openstack-trove | 06:12 | |
| *** ashestakov has joined #openstack-trove | 06:13 | |
| *** ashestakov has quit IRC | 06:18 | |
| openstackgerrit | Sushil Kumar proposed a change to openstack/trove: Removes assertThat usage with testtools.matchers https://review.openstack.org/67811 | 06:25 |
| *** SushilKM has quit IRC | 06:30 | |
| openstackgerrit | Tim Simpson proposed a change to openstack/trove: Changing DNS to pass string to driver https://review.openstack.org/69480 | 06:33 |
| openstackgerrit | Tim Simpson proposed a change to openstack/trove: Changing DNS to pass string to driver https://review.openstack.org/69480 | 06:40 |
| openstackgerrit | Tim Simpson proposed a change to openstack/trove: Makes the backup tests less onerous https://review.openstack.org/69429 | 06:41 |
| *** michael-yu has joined #openstack-trove | 06:44 | |
| *** michael-yu has quit IRC | 06:55 | |
| *** SushilKM has joined #openstack-trove | 06:57 | |
| *** SnowDust has quit IRC | 07:08 | |
| *** arborism has joined #openstack-trove | 07:10 | |
| *** arborism is now known as amcrn | 07:10 | |
| *** igor has quit IRC | 07:17 | |
| *** SnowDust has joined #openstack-trove | 07:26 | |
| *** grapex has quit IRC | 07:28 | |
| *** erkules_ is now known as erkules | 07:34 | |
| *** flaper87|afk is now known as flaper87 | 07:44 | |
| *** SushilKM has quit IRC | 07:45 | |
| *** shivamshukla has quit IRC | 07:46 | |
| *** khyati has quit IRC | 07:48 | |
| *** igor has joined #openstack-trove | 07:50 | |
| *** michael-yu has joined #openstack-trove | 07:52 | |
| *** SushilKM has joined #openstack-trove | 07:54 | |
| *** igor_ has joined #openstack-trove | 07:54 | |
| *** ashestakov has joined #openstack-trove | 07:55 | |
| *** igor_ has quit IRC | 07:56 | |
| *** igor_ has joined #openstack-trove | 07:58 | |
| *** igor has quit IRC | 07:58 | |
| *** SnowDust has left #openstack-trove | 08:05 | |
| *** dougshelley66 has quit IRC | 08:19 | |
| *** dougshelley66 has joined #openstack-trove | 08:21 | |
| *** michael-yu has quit IRC | 08:24 | |
| *** SushilKM has quit IRC | 08:35 | |
| *** SushilKM has joined #openstack-trove | 08:38 | |
| *** yogesh has quit IRC | 08:58 | |
| *** SushilKM has quit IRC | 09:02 | |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 09:08 | |
| *** matsuhashi has quit IRC | 09:09 | |
| *** matsuhas_ has joined #openstack-trove | 09:14 | |
| openstackgerrit | Alexander Ignatov proposed a change to openstack/python-troveclient: Remove copyright from empty files https://review.openstack.org/67760 | 09:29 |
| *** matsuhas_ has quit IRC | 10:22 | |
| *** matsuhashi has joined #openstack-trove | 10:31 | |
| *** ashestakov has quit IRC | 10:37 | |
| *** amcrn has quit IRC | 10:52 | |
| *** matsuhashi has quit IRC | 11:00 | |
| *** ashestakov has joined #openstack-trove | 11:06 | |
| *** matsuhashi has joined #openstack-trove | 11:14 | |
| *** matsuhashi has quit IRC | 11:17 | |
| *** SergeyLukjanov is now known as SergeyLukjanov_a | 11:19 | |
| *** SergeyLukjanov_a is now known as SergeyLukjanov | 11:19 | |
| openstackgerrit | A change was merged to openstack/trove: Corrects help messages in cfg.py https://review.openstack.org/68717 | 11:25 |
| *** vipul has quit IRC | 12:10 | |
| *** vipul has joined #openstack-trove | 12:12 | |
| *** amrith has quit IRC | 12:52 | |
| *** jimbobhickville has joined #openstack-trove | 12:54 | |
| *** haomaiwa_ has quit IRC | 13:06 | |
| *** haomaiwang has joined #openstack-trove | 13:07 | |
| *** nosnos has quit IRC | 13:08 | |
| *** freyes has joined #openstack-trove | 13:18 | |
| *** haomaiwang has quit IRC | 13:24 | |
| *** haomaiwang has joined #openstack-trove | 13:24 | |
| *** pdmars has joined #openstack-trove | 13:27 | |
| *** Barker has joined #openstack-trove | 14:00 | |
| *** shivamshukla has joined #openstack-trove | 14:06 | |
| *** radez_g0n3 is now known as radez | 14:07 | |
| *** amrith has joined #openstack-trove | 14:12 | |
| *** dkehn_ has joined #openstack-trove | 14:15 | |
| *** grapex has joined #openstack-trove | 14:17 | |
| openstackgerrit | Eugeniya Kudryashova proposed a change to openstack/python-troveclient: Use Resource() class from common Oslo code https://review.openstack.org/63160 | 14:28 |
| *** jcru has joined #openstack-trove | 14:32 | |
| *** plodronio has joined #openstack-trove | 14:47 | |
| *** flaper87 is now known as flaper87|afk | 14:50 | |
| *** kevinconway has joined #openstack-trove | 15:06 | |
| *** rwsu has joined #openstack-trove | 15:12 | |
| *** haomaiwang has quit IRC | 15:16 | |
| *** tanisdl has joined #openstack-trove | 15:17 | |
| *** thedodd has joined #openstack-trove | 15:26 | |
| *** datsun180b has joined #openstack-trove | 15:36 | |
| *** SushilKM has joined #openstack-trove | 15:43 | |
| *** ViswaV has joined #openstack-trove | 15:56 | |
| *** ViswaV_ has joined #openstack-trove | 15:58 | |
| *** freyes has quit IRC | 16:01 | |
| *** ViswaV has quit IRC | 16:01 | |
| *** haomaiwang has joined #openstack-trove | 16:03 | |
| *** Barker has quit IRC | 16:06 | |
| *** SushilKM has quit IRC | 16:06 | |
| *** Barker has joined #openstack-trove | 16:07 | |
| *** jcooley_ has joined #openstack-trove | 16:09 | |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 16:09 | |
| *** flaper87|afk is now known as flaper87 | 16:12 | |
| *** igor_ has quit IRC | 16:17 | |
| *** igor_ has joined #openstack-trove | 16:18 | |
| *** ViswaV_ has quit IRC | 16:18 | |
| *** SushilKM has joined #openstack-trove | 16:22 | |
| *** ViswaV has joined #openstack-trove | 16:32 | |
| SushilKM | hub_cap, slicknik, vipul can i find u | 16:47 |
| *** boden has joined #openstack-trove | 17:18 | |
| boden | hi guys.. quick question I'm hoping someone can help me with... is no-db access implemented in the current trove-guestagent? I saw an implemented blueprint for trove-conductor seeming to indicate it was, but the trove-guestagent appears to still be looking for db access | 17:23 |
| *** flaper87 is now known as flaper87|afk | 17:28 | |
| *** boden has quit IRC | 17:33 | |
| ViswaV | Hi guys. Good morning. Quick question: I am trying to do a quick estimation on what changes might be needed to add support for mysql 5.6 (and possibly percona 5.6) as well. I captured percona related changes in a gist as a reference: https://gist.github.com/vvutharkar/8672197 | 17:33 |
| *** boden_ has joined #openstack-trove | 17:33 | |
| ViswaV | It would seem to me, that if I looked at mysql5.6 as mirroring close to percona…then there are very few changes on trove side to get it going….basically some /etc configs, dbaas.py to add the manager and tests…thats it…right? | 17:34 |
| *** michael-yu has joined #openstack-trove | 17:35 | |
| ViswaV | On the redstack side, all the usual stuff to create the image… and during setting up the datastore it can either be setup as a separate datastore OR same as 'mysql' datastore with different datastore_Version_id…. | 17:35 |
| *** SushilKM has quit IRC | 17:35 | |
| hub_cap | boden_: datsun180b would know, but thre should be no connecting to the db from the guest | 17:36 |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 17:36 | |
| hub_cap | if ther is, its a bug :) | 17:36 |
| hub_cap | ViswaV: iirc u can pass kick-start percona right now and itll run percona mysql | 17:36 |
| ViswaV | understood. | 17:37 |
| ViswaV | What I am looking for is mysql 5.6 and possibly percona 5.6 as well... | 17:37 |
| ViswaV | Assuming the same mysql manager would work, the changes on trove side (guestagent included) is minimal. If the mgmt of mysql 5.6 is different to 5.5 then all that is needed is a new datastore manager class for it…right? | 17:37 |
| hub_cap | correct | 17:38 |
| ViswaV | percona implementation seems to piggyback a lot on existing mysql stuff including using the same mysql manager as it's manager. | 17:38 |
| hub_cap | and the datastore version would be set as such | 17:38 |
| hub_cap | yup there shouldnt be any diffs | 17:38 |
| ViswaV | Would it be ok if I created couple of BPs (1) mysql 5.6 support on trove 2) mysql 5.6 image creation support on redstack ) and get to working on those? Possibly even do the same for percona 5.6 too? | 17:39 |
| *** SushilKM has joined #openstack-trove | 17:40 | |
| *** michael-yu has quit IRC | 17:42 | |
| ViswaV | Also as the datastore (+ different versions) keeps growing, the redstack int-tests/blackbox tests that I assume run "redstack kick-start <datastore>" and then subsequently test CRUD ops , would keep growing if you multiplex the same tests for different datastores being supported eventually…. The time taken to run the tests will also go up by n times… if they are continued to run the same way (the long pole is image creation) | 17:43 |
| ViswaV | I am assuming there is a better strategy in future …or possibly not all datastores need be tested for GATING purposes I assume? | 17:43 |
| ViswaV | Currently do the gating tests only create mysql image and test CRUD on that alone or do they also create percona, redis as well ? | 17:44 |
| ViswaV | hub_cap: thx for clarifying the percona/mysql stuff... | 17:45 |
| *** SushilKM has quit IRC | 17:45 | |
| *** boden_ has quit IRC | 17:50 | |
| *** boden has joined #openstack-trove | 17:50 | |
| *** esp has joined #openstack-trove | 17:51 | |
| hub_cap | so sure on the 5.6 support | 17:52 |
| hub_cap | wrt testing, we hope to solve some of this w/ our yet to be completed tempest tests, but SlickNik knows this is a requirement | 17:52 |
| hub_cap | everythign is tested via mysql + the old installation (ie no heat) | 17:53 |
| ashestakov | ViswaV: hub_cap percona 5.6 same as mysql 5.6 works with trove | 17:53 |
| hub_cap | so we have major patches of code thats not properly tested :) | 17:53 |
| ashestakov | i tested they when worked with multiple datastores | 17:53 |
| hub_cap | ashestakov: all aspects of it are the same? thre is _no_ reason for a different manager youre saying? | 17:54 |
| hub_cap | even when we get to clustering and such/ | 17:54 |
| hub_cap | ? | 17:54 |
| ashestakov | hub_cap: no, its wny i made lot of changes in manager | 17:55 |
| ashestakov | for clustering not tested, coz i got conflict in configs | 17:55 |
| hub_cap | bbl, ViswaV and ashestakov , yall chat about this | 17:55 |
| ViswaV | sorry….pardon my ignorance here… ashestakov how did you test percona and mysql 5.6? just some quick coding changes locally on your end? | 17:55 |
| ashestakov | galera doent support query cache, which is enabled in default config | 17:55 |
| *** demorris has joined #openstack-trove | 17:56 | |
| ViswaV | otherwise, I don't see it as a simple "pass a different param to redstak…..change some configs"…some code changes required too…no? | 17:56 |
| boden | hi datsun180b -- can you please confirm my previous question? i.e. the guest agent should not need direct database access and now uses conductor (via AMQP)? | 17:56 |
| datsun180b | hello what now | 17:57 |
| ashestakov | how i tested, install packages on vanilla images (ubuntu, centos and fedora), and move to RUNNING state, also checked mysql console | 17:57 |
| boden | datsun180b... paste --> hi guys.. quick question I'm hoping someone can help me with... is no-db access implemented in the current trove-guestagent? I saw an implemented blueprint for trove-conductor seeming to indicate it was, but the trove-guestagent appears to still be looking for db access | 17:57 |
| datsun180b | guest agents should not need to have a connection to the host database, no | 17:58 |
| kevinconway | you mean db access to the host db or the guest db? i'm pretty sure the mysql manager uses a pymysql connector to communicate with the guest | 17:58 |
| *** amcrn has joined #openstack-trove | 17:58 | |
| datsun180b | now to the guest db, that's a different story. it needs that | 17:59 |
| datsun180b | otherwise how can it perform actions like user and database creation | 17:59 |
| ashestakov | ah, aslo i tested mariadb 5.5 and 10.0, works both | 17:59 |
| boden | datsun180b --datsun180b -- ok maybe that is my problem... I will dig a bit | 17:59 |
| ViswaV | ashestakov: so you mention "its wny i made lot of changes in manager" …. I assume then that the default CRUD ops provided by the default mysql manager does not work out of box for 5.6.... | 17:59 |
| ashestakov | i fixed manager class to support all most known mysql versions | 18:00 |
| ViswaV | ashestakov: so…a question here ..what is a recommended approach that works best here: Single manager class for all versions of a datastore and it's close related cousins (mysql 5.5, 5.6, percona 5.5, 5.6) ? | 18:01 |
| *** khyati_ has joined #openstack-trove | 18:01 | |
| ViswaV | Or different managers extending off of a common base? | 18:01 |
| ViswaV | If you had a single class then I guess there might be lots of "if this version do this, else that" type of logic, that may not look clean... | 18:02 |
| ashestakov | single manager should works with all versions | 18:02 |
| kevinconway | ashestakov: i'm pretty sure managers are now assigned to the version | 18:02 |
| ashestakov | but you can add different manager class to support uncommon installations | 18:03 |
| ViswaV | Yes. Understood. for closely related family of datastores (minor version diffs, different vendor implementation of same DB etc), I think that would hold good.. at least for basic common CRUD ops. | 18:04 |
| *** yogesh has joined #openstack-trove | 18:05 | |
| ViswaV | ashestakov: are you planning on merging your enhanced manager code into master any time soon? I would be glad to help in testing , making any other changes etc. I was going to create a BP to add support for mysql/percona 5.6 | 18:05 |
| ashestakov | it already merged | 18:05 |
| ashestakov | while ago, with multiple datastores support | 18:06 |
| ashestakov | if no one broke it, should works | 18:07 |
| ViswaV | https://github.com/openstack/trove/blob/master/trove/guestagent/dbaas.py#L36 ….is there no need to add 'mysql56', 'percona56' in there? | 18:08 |
| ViswaV | btw, that brings up another question | 18:09 |
| ViswaV | defaults = { | 18:09 |
| ViswaV | 'mysql': 'trove.guestagent.datastore.mysql.manager.Manager', | 18:09 |
| ViswaV | 'percona': 'trove.guestagent.datastore.mysql.manager.Manager', | 18:09 |
| ViswaV | 'redis': 'trove.guestagent.datastore.redis.manager.Manager', | 18:09 |
| ViswaV | } | 18:09 |
| ViswaV | The code in this dbaas.py class tries to associate 'manager' to datastore name. whereas due to recent changes manager is tied to 'datastore_version_id' ……are some changes needed here in that context? | 18:10 |
| ViswaV | May be there is some more code like this …. I am still feeling my way around the code…so please correct me if I am misunderstanding something here... | 18:10 |
| kevinconway | i think that was left over from when we used to have SERVICE_TYPE | 18:11 |
| kevinconway | and trove only served on type | 18:11 |
| ViswaV | Same thing here… https://github.com/openstack/trove/blob/master/etc/trove/trove-guestagent.conf.sample#L31 | 18:12 |
| ViswaV | kevinconway: so does that piece of code and the conf entry need changes to align with manager<==>datastore_version_id update? | 18:12 |
| *** ashestakov has quit IRC | 18:15 | |
| kevinconway | it's probably going to either be that or remove it | 18:15 |
| kevinconway | i'm trying to figure out where it's actually used | 18:15 |
| ViswaV | thx. Also I remember there is another conf file that comes into picture in the DB instance .... | 18:16 |
| kevinconway | man, i'm not seeing where that mapper gets used | 18:17 |
| *** harlowja_away is now known as harlowja | 18:17 | |
| kevinconway | there's a function in the same file that uses it but i never see that function called except in tests | 18:17 |
| ViswaV | the file in the DB instances (guest) is /etc/guest_info | 18:18 |
| ViswaV | that also has a mapping "datastore_manager=mysql" ….again name to manager and not version to manager.... | 18:19 |
| ViswaV | Also it is confusing what is the override/preference priority order….which setting supersedes others? | 18:19 |
| ViswaV | I see that …https://github.com/openstack/trove/commit/f14c87f015a99221467a127568b13b9fa717a29f was done by cp16net: may be he can clarify some of these things? cp16net: u there? | 18:22 |
| ViswaV | https://github.com/openstack/trove/commit/f14c87f015a99221467a127568b13b9fa717a29f | 18:23 |
| *** michael-yu has joined #openstack-trove | 18:23 | |
| amcrn | ViswaV: 'manager' is effectively the logical-to-physical mapping from a datastore-version to a concrete class. versions belonging to the type can choose to share a manager if they behave the same, or they can diverge otherwise. what's your exact question? | 18:24 |
| ViswaV | amcrn: that part is clear to me. But from where does the datastore-version--> manager mapping derived from? As mentioned above there is dbaas.py, trove-guestagent.conf setting and then the /etc/guest_info (i think which gets injected as server-profile when 'trove create' happens) | 18:26 |
| amcrn | the manager is stored in the datastore_version table, which is managed by trove-manage | 18:27 |
| ViswaV | So my question is, all of these settings are mapping a 'datastore-name' to manager and not 'version' to manager. And secondly what is the order of precendence... | 18:27 |
| *** datsun180b has quit IRC | 18:27 | |
| ViswaV | So I am taking it that datastore_version table entries is the authoritative truth source...? | 18:27 |
| openstackgerrit | Robert Myers proposed a change to openstack/trove: Simplify swift storage load logic https://review.openstack.org/57796 | 18:28 |
| amcrn | for the manager tied to a respective version, yes. | 18:28 |
| amcrn | the registration of managers to classes for various strategies is in the code itself. | 18:28 |
| ViswaV | and that is the info that is propogated to the guest via /etc/guest_info during guest provisioning/bootup time... | 18:28 |
| amcrn | https://github.com/openstack/trove/blob/4420b8e76ec20b241ff6f2f706a505a97a117018/trove/taskmanager/models.py#L303 | 18:29 |
| ViswaV | amcrn: could you please elaborate "the registration of managers to classes for various strategies is in the code itself." ? | 18:29 |
| amcrn | https://github.com/openstack/trove/blob/master/trove/guestagent/dbaas.py#L36-L40 | 18:30 |
| *** michael-yu has quit IRC | 18:30 | |
| ViswaV | I think i get it now.. | 18:31 |
| amcrn | + https://github.com/openstack/trove/blob/a665911cd6b14afeb291aab2a0316bb89a10cd81/etc/trove/trove-guestagent.conf.sample#L31 | 18:31 |
| amcrn | (the extension, well, being an extension) | 18:31 |
| *** michael-yu has joined #openstack-trove | 18:31 | |
| ViswaV | both those pieces map datastore-manager-name (logical) to the actual class…. and not datastore-name to actuall manager class as I misunderstood. | 18:31 |
| ViswaV | And from the datastore-version-id table "a particular datastore version is mapped to a logical datasore-manager-name" | 18:32 |
| amcrn | guest_info has manager, manager is retrieved from version | 18:32 |
| amcrn | registry has manager to class | 18:33 |
| ViswaV | understood. Thx for clarification ! | 18:33 |
| *** yogesh has quit IRC | 18:34 | |
| amcrn | as to whether you should use a single class, or subclass, or <whatever>, do what makes sense; but don't attempt to anticipate divergence where it might not exist | 18:34 |
| ViswaV | Sure. It would seem based on ashestakov: assertion above that the existing 'mysql' manager should correctly handle mysql 5.6 already. | 18:36 |
| amcrn | as far as i'm aware, given the operations that are supported in trove today, there is no difference between 5.5 and 5.6; except the possibility of backups (that i'm not sure) | 18:37 |
| ViswaV | amcrn: understood. | 18:38 |
| amcrn | so, given the above, the existing manager *could* (and likely will) work. | 18:39 |
| ViswaV | amcrn: yes. That is my understanding so far from the above conversations. Will test it out. | 18:39 |
| *** edmund1 has joined #openstack-trove | 18:40 | |
| *** jmontemayor has joined #openstack-trove | 18:42 | |
| openstackgerrit | Andreas Jaeger proposed a change to openstack/database-api: Exclude files from testing https://review.openstack.org/69693 | 18:43 |
| *** datsun180b has joined #openstack-trove | 18:45 | |
| *** jmontemayor has quit IRC | 18:47 | |
| *** jmontemayor has joined #openstack-trove | 18:48 | |
| *** ashestakov has joined #openstack-trove | 18:48 | |
| *** Ranjitha has joined #openstack-trove | 18:48 | |
| *** jmontemayor has quit IRC | 18:49 | |
| *** datsun180b has quit IRC | 18:49 | |
| *** jmontemayor has joined #openstack-trove | 18:49 | |
| *** datsun180b has joined #openstack-trove | 18:50 | |
| *** jmontemayor_ has joined #openstack-trove | 18:51 | |
| *** jmontemayor_ has quit IRC | 18:51 | |
| *** zacksh has quit IRC | 18:51 | |
| *** zacksh_ has joined #openstack-trove | 18:51 | |
| *** jmontemayor has quit IRC | 18:52 | |
| *** SnowDust has joined #openstack-trove | 18:56 | |
| *** jmontemayor has joined #openstack-trove | 18:56 | |
| *** jmontemayor has quit IRC | 18:59 | |
| *** jmontemayor has joined #openstack-trove | 19:00 | |
| openstackgerrit | A change was merged to openstack/database-api: Exclude files from testing https://review.openstack.org/69693 | 19:01 |
| *** jimbobhickville has quit IRC | 19:14 | |
| *** thedodd has quit IRC | 19:14 | |
| *** rwsu has quit IRC | 19:36 | |
| *** rwsu has joined #openstack-trove | 19:40 | |
| *** SnowDust has quit IRC | 19:44 | |
| *** michael-yu has quit IRC | 19:46 | |
| *** denis_makogon has joined #openstack-trove | 19:47 | |
| *** michael-yu has joined #openstack-trove | 19:48 | |
| denis_makogon | whazaaap | 19:49 |
| *** zacksh_ is now known as zacksh | 19:49 | |
| juice | we are not ignoring you all - the HP team (vipul, slicknik, esmute, esp, juice) are at a company event | 19:50 |
| juice | 'til 5 pm PST | 19:50 |
| ViswaV | denis_makogon: good timing. Have a question… https://github.com/openstack/trove-integration/blob/master/scripts/redstack#L272 , that function should ideally take version as an input param as well rather than hardcoding… this is to support setting up image <--> datastore version relation for different versions of a given datastore (mysql 5.5 & mysql 5.6 for eg) | 19:52 |
| ViswaV | (see past mesgs for some of the context around mysql5.6 … ) | 19:53 |
| denis_makogon | ViswaV, with correct trove.conf from /etc/trove/trove.conf you could use trove-manage util to set packagest as you wish | 19:54 |
| denis_makogon | ViswaV, redstack script is built for install-and-use purposes | 19:54 |
| ViswaV | yes. If I wanted to build say "redstack kick-start mysql" that builds mysql 5.5 image for me and registers into trove DB. But to support mysql 5.6 , need to have the corresponding install.d etc elements as well as the option to take in the version and build the 5.6 image instead of default 5.5 image…right? Not sure where /etc/trove/trove.conf comes into picture? | 19:56 |
| *** SnowDust has joined #openstack-trove | 19:57 | |
| *** ashestakov has quit IRC | 19:59 | |
| *** SnowDust has quit IRC | 20:00 | |
| *** freyes has joined #openstack-trove | 20:00 | |
| *** igor_ has quit IRC | 20:02 | |
| openstackgerrit | Robert Myers proposed a change to openstack/trove: Adding Incremental Backups https://review.openstack.org/59568 | 20:03 |
| *** tanisdl has quit IRC | 20:05 | |
| *** tanisdl has joined #openstack-trove | 20:07 | |
| denis_makogon | ViswaV, you still could update datastore_version | 20:08 |
| denis_makogon | ViswaV, and set package mysql-server-5.6 | 20:08 |
| denis_makogon | ViswaV, guest will install given packages | 20:09 |
| *** freyes has quit IRC | 20:09 | |
| ViswaV | denis_makogon: … sure… But to be able to allow users to use redstack in the same manner they use today to build mysql 5.5 and be able to optionally build 5.6 instead, we need to be able to let them pass run "redstack kick-start mysql 5.6" or "redstack kick-start mysql56" …. either one would work. | 20:11 |
| denis_makogon | ViswaV, i really don't see a problem in this | 20:12 |
| denis_makogon | ViswaV, just use trove-manage | 20:12 |
| ViswaV | denis_makogon: sure. the quesiton then would be why do we have percona, redis (and mongodb from your other patch) in the redstack script then? those could have been added via trove-manage too…right? | 20:14 |
| ViswaV | Just trying to understand if whatever is the use case for adding those into redstack, is also going to have to be supported for mysql5.6 or not? | 20:15 |
| denis_makogon | ViswaV, what's the huge difference between 5.5 and 5.6 ? | 20:17 |
| ViswaV | Nothing on the trove guest agent side as of now, from what I learnt from today's conversations with amcrn and ashestakov. Only diff is that it is a different package, but managed by same troveguest agent/manager etc. | 20:18 |
| kevinconway | denis_makogon: i think he's saying that in order to test different versions of a datastore we need to be able to kickstart them independently | 20:19 |
| denis_makogon | kevinconway, thanks, but i understood what ViswaV saying | 20:20 |
| ViswaV | http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html says replication aspects are improved a lot… so in future may be the 'manager' implementation will have to differ/augmented for 5.6 | 20:20 |
| kevinconway | ViswaV could "kick-start mysql" and "kick-start mysql56" work for adding new versions? | 20:20 |
| kevinconway | and you just add another entry to redstack to name the packages | 20:21 |
| denis_makogon | ViswaV, i would say that redstack doesn't need this, you could do that manualy | 20:21 |
| ViswaV | I think it would…just from my quick look at the redstack script… that would eliminate the need to pass in extra param. just define new type 'mysql56' as you mention | 20:21 |
| ViswaV | (that was response to kevin) | 20:21 |
| kevinconway | i'm still curious to see how the tempests tests account for this | 20:22 |
| kevinconway | or if it will even use kick-start | 20:22 |
| denis_makogon | setup hook ? | 20:22 |
| kevinconway | because if we have a base image for all the tests and just create a new datastore for a mysql-5.6 test suite | 20:22 |
| ViswaV | it would be good to know what use case(s) require adding support for a new datastore or a new version of existing datastore into redstack? | 20:23 |
| kevinconway | ViswaV: so far we are only adding types | 20:23 |
| kevinconway | each just has one version | 20:23 |
| denis_makogon | ViswaV, mysql-5.5 and 5.6 versions are still mysql, trove could do "install" for all of them | 20:23 |
| ViswaV | so the intention is to cover different datastores (since their manager implementations could be different) ? | 20:24 |
| denis_makogon | there's huge difference betwee adding new datastore support and adding new version to existed datastore | 20:24 |
| ViswaV | agree completely. | 20:24 |
| denis_makogon | manager for 5.5 and 5.6 is common | 20:25 |
| kevinconway | denis_makogon: well… there *will* be a difference once updates/migrations are ready | 20:25 |
| ViswaV | I was gonna say that is the underlying assumption …. the manager is common. | 20:25 |
| denis_makogon | kevinconway, yes, i just started typing it, you've stole my words | 20:25 |
| ViswaV | So is it correct to say that , ONLY if the manager is different , then it might make a good case to add support for that datastore (or just diff version of a datastore) in the redstack? | 20:26 |
| kevinconway | denis_makogon: *shang tsung* your words are mine! | 20:26 |
| denis_makogon | ViswaV, yes | 20:26 |
| denis_makogon | kevinconway, mortal combat ?))) | 20:26 |
| ViswaV | denis_makogon: so would you say then that https://blueprints.launchpad.net/trove-integration/+spec/base-mysql5.6-image is not needed … at least not until the manager implementations for 5.5 and 5.6 start to differ? | 20:27 |
| denis_makogon | ViswaV, yes | 20:30 |
| denis_makogon | ViswaV, i would say, that it would be nice to update current version of packages to mysql-server-5.6 | 20:30 |
| denis_makogon | ViswaV, you could deal with it | 20:31 |
| denis_makogon | ViswaV, lets say, mysql-5.5 is old peace of junk, let's be up-to-date | 20:31 |
| ViswaV | so make the default 'mysql' be 5.6 instead of 5.5? | 20:32 |
| hub_cap | hey denis_makogon did u get my msg about cassandra? i tried to install/run it on 2 different vms, and it hung up | 20:32 |
| denis_makogon | hub_cap, yes, i'm almost done it | 20:33 |
| kevinconway | hub_cap: did you call it back? lolololol | 20:33 |
| *** amrith has quit IRC | 20:33 | |
| denis_makogon | hub_cap, gonna submit new patch tomorrow, i traveled a bit | 20:34 |
| *** amrith has joined #openstack-trove | 20:34 | |
| hub_cap | denis_makogon: <3 | 20:34 |
| ViswaV | denis_makogon: wouldn't 5.6 vs 5.5 be determined by how many DBAs out there still consider 5.5 stable and rely and use it heavily? Can we make that call within this group without additional data about industry usage? | 20:34 |
| hub_cap | kevinconway: i dont get the refernce :( | 20:34 |
| denis_makogon | hub_cap, now i'm back and ready to do magic | 20:34 |
| kevinconway | hub_cap: awe… was going for bad joke. it hung up on you => did you call it back. you know. like a phone | 20:35 |
| denis_makogon | ViswaV, ask dudes who use trove in production | 20:35 |
| kevinconway | but now that i've had to explain it... | 20:35 |
| denis_makogon | kevinconway, lol | 20:35 |
| * amcrn ba dum tss | 20:35 | |
| denis_makogon | hub_cap, which mysql version are Rax using in production ? | 20:36 |
| hub_cap | denis_makogon: youd have to ask demorris or grapex | 20:36 |
| kevinconway | ViswaV: the kick-start isn't really a prep for production ready service | 20:36 |
| hub_cap | im community :) | 20:36 |
| kevinconway | it's just for local dev and testing | 20:36 |
| kevinconway | in prod you would set whichever datastore types and versions you needed | 20:37 |
| hub_cap | kevinconway: smh | 20:37 |
| kevinconway | hub_cap: ? | 20:37 |
| ViswaV | kevinconway: agree… it's just additional assurance that the automated redstack int-tests are passing for a particular datastore/version, thusly putting an approval stamp on quality of manager/guestagent code... | 20:37 |
| hub_cap | kevinconway: your terrible joke | 20:38 |
| kevinconway | ViswaV: i see what you mean. that makes sense | 20:38 |
| *** igor_ has joined #openstack-trove | 20:40 | |
| ViswaV | Our internal requirement is for 5.6 support…and thereby people are looking for that 'approval of quality' stamp via whatever automated tests that exist today in trove/redstack project. Additionally, manual tests will also be run for sure before deployment to prod, but you know what I mean. | 20:41 |
| kevinconway | maybe hub_cap has some insight on that | 20:42 |
| hub_cap | i think we can cross the bridge once we need a 5.6 datastore mgr (in theory u can use the regular mysql manager w/ 5.6 currently) | 20:43 |
| kevinconway | that's called a punt. it's what i do when i realize a conversation is over my paygrade | 20:43 |
| hub_cap | heh kevinconway | 20:43 |
| ViswaV | :) | 20:44 |
| kevinconway | oh i was thinking. you should be able to do "PACKAGE='mysq-5.6' kick-start mysql" | 20:44 |
| kevinconway | and then run int tests to try | 20:44 |
| kevinconway | we made the installable package string a variable you can set | 20:44 |
| ViswaV | Ah…that's a handy little feature ! | 20:45 |
| ViswaV | Thx | 20:45 |
| kevinconway | ViswaV: https://github.com/openstack/trove-integration/blob/master/scripts/redstack#L277 | 20:45 |
| kevinconway | its PACKAGES | 20:45 |
| kevinconway | so the version will still say 5.5 in the trove database, but 5.6 will get installed on your guest | 20:45 |
| ViswaV | Will try that. So that should build a 5.6 image, correct ? | 20:46 |
| kevinconway | my understanding is that the images themselves are just basic OS images | 20:46 |
| kevinconway | the guest installs the db | 20:46 |
| ViswaV | https://github.com/openstack/trove-integration/blob/master/scripts/redstack#L280 … VERSION is getting hardcoded… :( | 20:46 |
| kevinconway | ViswaV: you could modify that function to make VERSION work just like PACKAGES | 20:47 |
| ViswaV | my understanding was that the disk-image-builder builds the specific app into the base image (utilizing the various elements scripts, install.d etc) | 20:47 |
| kevinconway | so kick-start mysql by default is 5.5, but VERSION=5.6 kick-start mysql is 5.6 | 20:47 |
| ViswaV | kevinconway: thats a better idea. | 20:47 |
| kevinconway | ViswaV: you *can* use elements, but they don't work do that now | 20:48 |
| kevinconway | or at least none of my instances provision with a db already installed | 20:48 |
| ViswaV | I am surprised. Once you finish redstack kickstart mysql and it loads the image into glance…if you then use nova to provision an instance of that image (not trove), you don't see mysql already installed in there? | 20:49 |
| ViswaV | It may not start up mysql, but it would already be installed ..right? | 20:50 |
| *** igor_ has quit IRC | 20:53 | |
| *** shivamshukla has quit IRC | 20:53 | |
| hub_cap | yea i think we install mysql by default, but if u specify the package, it shocul also check against that package (Version) and install that one if its not alreayd installed | 20:54 |
| ViswaV | hub_cap: what is "it" here… redstack kick-start script or the trove guestagent code when it comes up inside the instance? | 20:56 |
| ViswaV | btw, kevinconway, denis_makogon, hub_cap I really appreciate the time you are taking to answer a newbie's questions . Thx much. | 20:58 |
| hub_cap | guestagent code ViswaV | 20:58 |
| hub_cap | or thats the way it _should_ work :) | 20:59 |
| mat-lowery | I have a general comment/question regarding (1) conf (i.e. trove-{api,taskmanager,conductor,guestagent}.conf) vs. (2) db (specifically datastore_versions table) vs. (3) templates (excluding heat.template but instead whatever generates /etc/guest_info). | 20:59 |
| mat-lowery | A delineation that makes sense to me: (1) db is for compute-service config (e.g. image, secgroups) and (2) conf is for settings for the services themselves and (3) templates are for guestagent or the services it manages (e.g. my.cnf). | 20:59 |
| mat-lowery | So that you get the following usage: (1) conf is never touched unless you need to make service changes and (2) db is touched during trove create and (3) templates are external to trove codebase (outside dist-packages) so that I don't need to bounce trove processes to add a datastore. | 20:59 |
| *** Ranjitha has quit IRC | 21:00 | |
| mat-lowery | wasn't consistent with my numbers :( ^ | 21:01 |
| ViswaV | hub_cap: So if I create and setup a mysql (5.5) image via redstack kick-start mysql and then use trove-manage to set package and version as 5.6 , then when I provision an instance via "trove create", the guest agent would come up after the instance boots up and installs 5.6 on top of the existing 5.5 installation thusly overriding/updating the app? | 21:01 |
| boden | anyone happen to have a working sample trove-guestagent.conf they can share... of course secure/creds omitted? | 21:01 |
| hub_cap | ViswaV: i think thats the theory | 21:02 |
| *** michael-yu has quit IRC | 21:02 | |
| ViswaV | hub_cap: That would be amazing if it works. I will test it and share my findings. Thx. | 21:03 |
| hub_cap | if not, sounds like a good bug to fix ViswaV ;) | 21:03 |
| ViswaV | hub_cap: as long as it is the expected workflow/behavior I would be glad to test it and file/fix bug as required. | 21:04 |
| denis_makogon | boden, what the problem with /etc/trove-taskmanager.conf inside trove-integration ? | 21:04 |
| denis_makogon | ViswaV, i'd suggest you to try start mysql-5.6 with given mysql/config.template | 21:05 |
| denis_makogon | ViswaV, if it fits than, i suppose, nothing bug-like would happen | 21:05 |
| denis_makogon | *wouldn't | 21:06 |
| boden | denis_makogon: i assume the guest agent conf has sql_connection=xxx prop set for the guest's local mysql correct? | 21:06 |
| boden | local = mysql on the guest | 21:06 |
| denis_makogon | boden, mysql server which is common for whole stack | 21:07 |
| boden | denis_makogon: and does that guest mysql have any tables/databased on a "fresh" guest? | 21:07 |
| denis_makogon | boden, no | 21:08 |
| denis_makogon | boden, there are one mysql server which is shared between OpenStack services | 21:09 |
| denis_makogon | *there are two | 21:09 |
| denis_makogon | and second and VM where guest runs | 21:09 |
| denis_makogon | trove-guestagent should be able, for now, communicate with shared mysql server | 21:10 |
| denis_makogon | hub_cap, still here ? | 21:10 |
| boden | denis_makogon: yeah I think I got it... these would seem to be trivial questions, but actually constructing a custom guest | 21:10 |
| hub_cap | denis_makogon: in a meeting then leaving for a meetup this evening so, not really :) | 21:10 |
| denis_makogon | hub_cap, if you would have free 5 mins., could you please re-approve this one https://review.openstack.org/#/c/59410/ | 21:11 |
| denis_makogon | hub_cap, last patch - manual rebase | 21:11 |
| hub_cap | +2'd | 21:12 |
| mat-lowery | denis_makogon: Is now a good time to talk about https://review.openstack.org/50944? I would like to discuss the approach. | 21:12 |
| denis_makogon | hub_cap, as always <3 | 21:12 |
| denis_makogon | mat-lowery, we could try, but would be better to move this topic to meeting agenda | 21:13 |
| denis_makogon | mat-lowery, but we still able to talk about it | 21:13 |
| mat-lowery | denis_makogon: New to trove. I assume you mean add an item to tomorrow's weekly meeting? I can do whatever works for you. | 21:14 |
| denis_makogon | mat-lowery, since trove would support more than one datastore, we need to be able add rules for all possible ports | 21:15 |
| *** ViswaV has quit IRC | 21:15 | |
| denis_makogon | that is why taskmanager.conf would contain custom sections for all datastore | 21:15 |
| denis_makogon | *datastores | 21:15 |
| mat-lowery | denis_makogon: No question there. I just feel that db is the proper place for secgroup rules instead of conf. I had some points earlier that I can re-paste supporting that argument. Thoughts? | 21:16 |
| denis_makogon | mat-lowery, as i said in mail, we would have oslo section named same as datastore manager | 21:16 |
| mat-lowery | denis_makogon: db meaning datastore_versions table where other compute service config like image is kept | 21:17 |
| kevinconway | mat-lowery: usually we spit-ball ideas in irc | 21:17 |
| kevinconway | if it's going to be a long conversation we dump it into the mailing list so more people can give input | 21:17 |
| denis_makogon | mat-lowery, trove back end stores significant attributes | 21:17 |
| kevinconway | and then we bring things up at meetings to jumpstart ideas too | 21:17 |
| denis_makogon | mat-lowery, one question how we would add ports to version table > | 21:18 |
| denis_makogon | ? | 21:18 |
| mat-lowery | kevinconway: Thanks. I'm not sure if this is quick discussion or not. Feel free to tell me "move to mailing list or meeting" at any time. | 21:19 |
| denis_makogon | mat-lowery, trove has almost perfect models splitting | 21:19 |
| denis_makogon | mat-lowery, it has model for security groups/rules | 21:19 |
| denis_makogon | and that is fine | 21:19 |
| mat-lowery | denis_makogon: I thought about a single new column being a JSON string but I really was more concerned about delineation in general rather than details of the table. | 21:20 |
| mat-lowery | denis_makogon: I'm not saying change any of the secgroup models; just that instead of reading ports or port ranges from trove-taskmanager.conf, read it from db. Then there's no need to restart trove-taskmanager after adding a new datastore using trove create. | 21:21 |
| denis_makogon | mat-lowery, it's too complicated | 21:21 |
| kevinconway | mat-lowery: ew… json in mysql? | 21:21 |
| mat-lowery | kevinconway: There's a precedent in nova tables and possibly others. | 21:22 |
| *** ViswaV has joined #openstack-trove | 21:22 | |
| hub_cap | yea thats nothing new :) | 21:22 |
| mat-lowery | denis_makogon: Specifically, what is too complicated? | 21:22 |
| denis_makogon | mat-lowery, you still able to create new rules via trove security | 21:22 |
| denis_makogon | mat-lowery, you need to define new API which would manage those column, you need to give an ability to generic user to modify it | 21:24 |
| mat-lowery | denis_makogon: If you mean trove secgroup* commands, there's a subtle diff between applying the security group at creation vs. after-the-fact. | 21:24 |
| *** Ranjitha has joined #openstack-trove | 21:24 | |
| denis_makogon | mat-lowery, but version table is closed for all user, except admin | 21:24 |
| openstackgerrit | Robert Myers proposed a change to openstack/python-troveclient: Adding support for incremental backups https://review.openstack.org/63479 | 21:25 |
| mat-lowery | denis_makogon: I don't mean a new user-facing API; only new arg on trove-manage datastore_version_update. | 21:25 |
| boden | denis_makogon: so the mysql_connection property idenis_makogon: still missing a piece of puzzle... in the guest agent's conf, if there are no databases in mysql for a "fresh" guest instance, what database is specified on the mysql_connection property? | 21:25 |
| boden | sorry for the double mention | 21:26 |
| mat-lowery | denis_makogon: Summary of entire proposal: Instead of putting ports in trove-taskmanager.conf, put those ports in datastore_versions table. | 21:26 |
| *** michael-yu has joined #openstack-trove | 21:27 | |
| denis_makogon | mat-lowery, the only advantage of such proposal is to keep server-side always running ? | 21:28 |
| mat-lowery | denis_makogon: Responsibility of security group rules is pushed to operator. trove-taskmanager.conf doesn't grow in complexity as new datastores become standard. no need to restart trove-taskmanager, etc. Finally, there is a precedent for compute-server config in the database: the image id. | 21:28 |
| *** ramashri has joined #openstack-trove | 21:28 | |
| denis_makogon | mat-lowery, there's no precedent | 21:28 |
| denis_makogon | mat-lowery, image id is required | 21:29 |
| denis_makogon | without it you cannot get appropriate image from glance | 21:30 |
| denis_makogon | mat-lowery, image id for datastore is required, same as compute_instance_id, stack_id, security_group_id for trove instance | 21:30 |
| mat-lowery | denis_makogon: datastore_versions.image_id is passed all the way to nova (or heat). Same could be done for secgroup rules. | 21:30 |
| denis_makogon | mat-lowery, nova waits already existed security groups | 21:31 |
| denis_makogon | mat-lowery, but trove creates them separately | 21:31 |
| denis_makogon | mat-lowery, with configuration management, user would be able to modify database default ports as he wishes | 21:32 |
| mat-lowery | denis_makogon: I think we understand everything the other is saying. We just see it differently (probably wrongly in my case). | 21:33 |
| hub_cap | ugh kevinconway u ever dehilght trove in this channel? | 21:33 |
| denis_makogon | mat-lowery, take a look at amazon rds security groups | 21:34 |
| denis_makogon | boden, in guest conf specified database it external mysql server, which is shared between projects | 21:35 |
| kevinconway | hub_cap: nope, my client is going crazy of this convo | 21:35 |
| mat-lowery | denis_makogon: I'll check it out. Thanks for the discussion. | 21:36 |
| denis_makogon | mat-lowery, thanks to you | 21:36 |
| *** jimbobhickville has joined #openstack-trove | 21:37 | |
| denis_makogon | ViswaV, ping | 21:37 |
| hub_cap | mine too :) ive got to remove my hilight heh | 21:38 |
| boden | denis_makogon: so in the guest conf the mysql_connection points back to the mysql database used by the trove api/conductor/etc? | 21:38 |
| denis_makogon | boden, yes | 21:38 |
| ViswaV | Yes denis_makogon … had stepped away for grabbing a quick bite. | 21:38 |
| denis_makogon | ViswaV, https://review.openstack.org/#/c/50597/ you comments are out of scope | 21:38 |
| denis_makogon | ViswaV, trove definition is "Database-on-demand" | 21:39 |
| denis_makogon | ViswaV, so, it shoul get provisioned VMs with installed database in it, nothing else | 21:40 |
| ViswaV | denis_makogon "out of scope" from perspective of original BP ? | 21:40 |
| denis_makogon | ViswaV, yes | 21:40 |
| *** jimbobhickville has quit IRC | 21:41 | |
| denis_makogon | ViswaV, if you have IP of mongo server you could do anything with it, so, we (i and ikhudoshyn) would not implement users/database CRUD operations through trove | 21:42 |
| denis_makogon | ViswaV, take a look at support matrix for datastores | 21:42 |
| ViswaV | I was trying to make an argument for the 'user' creation support… basically commenting for the claim made in "https://blueprints.launchpad.net/trove/+spec/single-instance-mongodb-ga" | 21:42 |
| denis_makogon | ViswaV, as i said, we don't need it | 21:42 |
| ViswaV | so what would "trove user-create" output be for mongodb ? | 21:43 |
| ViswaV | "Not supported operation " ? | 21:43 |
| denis_makogon | ViswaV, HTTP 500 | 21:43 |
| ViswaV | And the justification would be? | 21:44 |
| denis_makogon | ViswaV, some sort | 21:44 |
| denis_makogon | ViswaV, trove is not a database client\ | 21:44 |
| ViswaV | If it is supported for mysql , and mongodb has similar root/admin user concept, then why not for mongodb? | 21:44 |
| kevinconway | ViswaV: there is a BP for defined capabilities of datastores | 21:45 |
| kevinconway | to help determine which support what calls | 21:45 |
| denis_makogon | ViswaV, mysql users/databases were requirement of customers | 21:45 |
| ViswaV | wouldn't mongodb customers have same requirements? Sorry…if I sound argumentative …just wanted to understand the logic for exclusion. Only info I had prior is "https://blueprints.launchpad.net/trove/+spec/single-instance-mongodb-ga". And it stated | 21:47 |
| amcrn | ViswaV: i think this discussion is a bit tangential; whether you should be able to create an admin or a user in mongodb is tangential to whether the first mongo patch-set can land as-is to achieve a minimally viable offering. | 21:47 |
| denis_makogon | ViswaV, so, i really don't think that trove should support database/user CRUD operations, because it ruines definition of "Database-as-a-Service" | 21:47 |
| *** igor_ has joined #openstack-trove | 21:47 | |
| kevinconway | ViswaV: we've had a contentious past when it comes to users | 21:47 |
| kevinconway | but something like redis, for example, won't support user calls | 21:48 |
| kevinconway | because it doesn't have them | 21:48 |
| denis_makogon | kevinconway, same as cassandra | 21:48 |
| ViswaV | Got it. Don't have the advantage of history... | 21:48 |
| hub_cap | denis_makogon: ViswaV yup. the 2.0 api will be much different from the perspective of users and dbs' :) | 21:48 |
| denis_makogon | hub_cap, thanks for wise words)) | 21:48 |
| ViswaV | amcrn: agree about the scope of original BP and the request being tangential.. | 21:48 |
| denis_makogon | ViswaV, why cannot you connect to mongo via any possible client ? | 21:49 |
| *** shakayumi has joined #openstack-trove | 21:49 | |
| denis_makogon | ViswaV, are there any problems with each of them ? | 21:49 |
| ViswaV | Reason for that comment was the argument presented in the BP (url above) and it seemed as if the only reason user support was not being added was because mongodb user model did not fit/mirror mysql and I found it to be otherwise… did not know the other historical contentions around user model support. | 21:50 |
| kevinconway | ViswaV: I'm of the opinion that if the datastore can support the call then it should | 21:51 |
| kevinconway | our history was related to how we should expose missing features | 21:51 |
| kevinconway | i think capabilities is what we're going to do | 21:51 |
| denis_makogon | ViswaV, just lettig you know, there are two definitions: "database-as-a-service" and "database-on-demand" - and they are totally differents | 21:51 |
| kevinconway | some metadata that describes which of the core api calls are impled | 21:51 |
| denis_makogon | ViswaV, database-as-a-service is Amazon DynamoDB | 21:52 |
| kevinconway | denis_makogon: i think he's asking why can't he make users through the trove api for mongo, not why can't he connect to mongo with the trove client | 21:52 |
| ViswaV | denis_makogon …100% agree.. It just seemed to be non-uniform approach that basic/common trove API/CLI do different things for different datastores even when underlying DBs support common baseline ops. That was the only concern that prompted me to make that comment. | 21:52 |
| denis_makogon | ViswaV, database-on-demand - Amazon RDS | 21:52 |
| denis_makogon | kevinconway, well, answer is clean enough, because it's impossible without changing API side totally | 21:53 |
| kevinconway | denis_makogon: why would mongo require api change for making users? | 21:53 |
| denis_makogon | kevinconway, validation first | 21:53 |
| *** igor_ has quit IRC | 21:53 | |
| ViswaV | can you please elaborate? | 21:53 |
| denis_makogon | kevinconway, models next | 21:54 |
| denis_makogon | ViswaV, trove-api performs users/database validation for mysql now | 21:54 |
| kevinconway | denis_makogon: i wasn't suggesting you use the mysql class for users and user validation | 21:54 |
| denis_makogon | kevinconway, there's no ability to make it pluggable | 21:54 |
| kevinconway | denis_makogon: for example, postgresql and mysql users are different | 21:55 |
| kevinconway | postgresql does not have a host | 21:55 |
| ViswaV | isn't it embedded in 'manager' ? If not, should it not ? | 21:55 |
| kevinconway | but i can still impl the users call | 21:55 |
| denis_makogon | kevinconway, does they work with current api and taskmanager side ? | 21:56 |
| kevinconway | denis_makogon: yes you can CRUD postgresql uses in my review | 21:56 |
| kevinconway | *users | 21:56 |
| denis_makogon | ViswaV, it's embedded to trove-api | 21:56 |
| kevinconway | oh no. i'm so sorry hub_cap. | 21:56 |
| kevinconway | we're talking about users.... | 21:56 |
| denis_makogon | but still, i don't see a use-case for users/database through trove | 21:57 |
| hub_cap | noooooooooooooooooooooooooooooooooooooooo | 21:57 |
| hub_cap | its ok im leavin | 21:57 |
| hub_cap | goin into the city for a meetup | 21:57 |
| hub_cap | see yall manana | 21:57 |
| denis_makogon | cu 2 | 21:57 |
| denis_makogon | ViswaV, people who uses mongo are able to write query to create new user | 21:58 |
| denis_makogon | ViswaV, so, in terms of this, and accoring to product definition - trove should not support user/database operation at all | 21:59 |
| *** SergeyLukjanov is now known as SergeyLukjanov_ | 21:59 | |
| ViswaV | denis_makogon: https://github.com/openstack/trove/blob/master/trove/guestagent/datastore/mysql/manager.py#L57 , so why can't the mongodb/manager.py have a working implementation for that method instead of returning http 500? | 22:00 |
| denis_makogon | ViswaV, the reason is clear - we should not do everything that mysql now has | 22:01 |
| ViswaV | nod. | 22:01 |
| denis_makogon | ViswaV, first of all, users/database operations is an extention | 22:01 |
| kevinconway | denis_makogon: I disagree that Trove should not support user/db calls | 22:02 |
| kevinconway | i think that's within the scope of managing the database | 22:02 |
| denis_makogon | kevinconway, then trove is not a database-as-a-service | 22:02 |
| denis_makogon | kevinconway, trove is a database-on-demand | 22:03 |
| kevinconway | what is the distinction? | 22:03 |
| denis_makogon | database-on-demand - only provisioning and admininstrative management | 22:04 |
| denis_makogon | database-as-a-service - data CRUD API, users API, database API, no administrative tasks | 22:04 |
| kevinconway | did you mix those up? | 22:05 |
| denis_makogon | as i said, Amazon RDS - database on demand | 22:05 |
| kevinconway | because by your definition Trove, and also mongo, should support users and b api | 22:05 |
| ViswaV | yes… I am a bit confused too now. | 22:06 |
| denis_makogon | kevinconway, trove is not database-on-demand | 22:06 |
| ViswaV | trove is dbaas ..right | 22:06 |
| kevinconway | ViswaV: i'm glad i'm not the only one confused | 22:06 |
| kevinconway | aaaaanyway, ViswaV this sounds like maybe we need some more voices | 22:07 |
| denis_makogon | Trove is a Database-on-demand | 22:07 |
| kevinconway | ViswaV: I would suggest ML maybe? | 22:07 |
| denis_makogon | database-as-a-service is a definition of Amazon DynamoDB | 22:07 |
| kevinconway | this way you can get your question out to some more people and denis_makogon can make his argument there for more to read | 22:07 |
| *** pdmars has quit IRC | 22:08 | |
| kevinconway | denis_makogon: i think most people will consider Trove to be db as a service | 22:08 |
| denis_makogon | database-on-demand - http://aws.amazon.com/rds/details/ | 22:08 |
| denis_makogon | database-as-a-service http://aws.amazon.com/dynamodb/ | 22:08 |
| denis_makogon | huge difference | 22:08 |
| denis_makogon | database-on-demand is a background layer of database-as-a-service | 22:09 |
| *** harlowja is now known as harlowja_away | 22:10 | |
| kevinconway | ViswaV: just put the tag [Trove] in your subject | 22:11 |
| kevinconway | people filter on that | 22:11 |
| ViswaV | I agree about the original scope of that BP, but I am glad about the comment :) Got to hear the history and the different perspectives around the user api support. Definitely a worthy topic of discussion dbaas, dbondemand, users etc. | 22:11 |
| kevinconway | denis_makogon: i think you're going to get some push back on defining Trove as something other than db as a service | 22:11 |
| ViswaV | Sure kevinconway. Will send an email out. | 22:12 |
| denis_makogon | kevinconway, customers requirements should not ruine open source project definition | 22:13 |
| denis_makogon | kevinconway, i suppose, API v2 would not have users | 22:14 |
| denis_makogon | and databases | 22:14 |
| denis_makogon | lets add data CRUD API, why not, it's also management | 22:15 |
| denis_makogon | ViswaV, i would not suggest you to send emain right now | 22:15 |
| denis_makogon | ViswaV, bring this topic to meeting | 22:15 |
| ViswaV | Not going to. Don't even know the right mailing list :) | 22:16 |
| denis_makogon | [openstack-dev] | 22:16 |
| denis_makogon | [trove] | 22:16 |
| ViswaV | denis_makogon: Thx. Anyway..I don't have the whole history:context…and I am sure this topic may have been discussed multiple times already (and will be discussed in future as well :) | 22:17 |
| *** harlowja_away is now known as harlowja | 22:18 | |
| ViswaV | To summarize I agree with the original scope of the mongodb initial BP. About the general overall support of user ..I guess for later …. that topic remains open and will come up whenever it's relevant again I guess. | 22:20 |
| ViswaV | Thx for sharing your thoughts on the topic. | 22:20 |
| ViswaV | denis_makogon: btw, please do let me know if any help is needed (in testing, patching etc) of the mongodb BPs… I am keenly interested in getting those merged soon. | 22:21 |
| denis_makogon | ViswaV, i'm going to test current patch as soon as i finish with cassandra | 22:22 |
| ViswaV | Thx ! | 22:22 |
| *** boden has quit IRC | 22:22 | |
| denis_makogon | ViswaV, thanks 2 u | 22:23 |
| *** amrith has quit IRC | 22:27 | |
| *** Ranjitha has quit IRC | 22:30 | |
| *** jimbobhickville has joined #openstack-trove | 22:31 | |
| *** amrith has joined #openstack-trove | 22:34 | |
| *** yogesh has joined #openstack-trove | 22:34 | |
| *** jimbobhickville has quit IRC | 22:35 | |
| *** yogesh has quit IRC | 22:39 | |
| *** Barker has quit IRC | 22:41 | |
| *** amrith has quit IRC | 22:47 | |
| *** igor_ has joined #openstack-trove | 22:48 | |
| *** igor_ has quit IRC | 22:54 | |
| *** jcru has quit IRC | 22:59 | |
| *** ViswaV has quit IRC | 23:02 | |
| *** openstack has joined #openstack-trove | 23:03 | |
| *** ViswaV has joined #openstack-trove | 23:06 | |
| ViswaV | denis_makogon , kevinconway got disconnected/reconnected and noticed this because of that…. the Topic of this channel disagrees with denis_makogon's dbaas vs dbod claim too :) | 23:12 |
| denis_makogon | ViswaV, dbaas came from past | 23:13 |
| ViswaV | lol…you are well prepared with your defence ! | 23:13 |
| ViswaV | btw, denis_makogon where are you from? | 23:16 |
| denis_makogon | ViswaV, Ukraine | 23:17 |
| ViswaV | My previous project had a team from Kiev. | 23:17 |
| ViswaV | Is the political/civil unrest there getting any close to closure? Looks like latest news seems to be positive development.. | 23:19 |
| ViswaV | denis_makogon ^^^ (keep forgetting to address nicknames of users to trigger alerts on their end) | 23:22 |
| denis_makogon | ViswaV, yes, news are a bit positive | 23:23 |
| denis_makogon | ViswaV, but we'er far away from stable living here | 23:23 |
| ViswaV | denis_makogon: hope it gets better. | 23:24 |
| denis_makogon | ViswaV, hope, we'll avoid civil war ... | 23:25 |
| *** jimbobhickville has joined #openstack-trove | 23:25 | |
| *** datsun180b has quit IRC | 23:27 | |
| *** jimbobhickville has quit IRC | 23:29 | |
| *** shakayumi has quit IRC | 23:31 | |
| *** kevinconway has quit IRC | 23:32 | |
| *** denis_makogon has quit IRC | 23:32 | |
| *** radez is now known as radez_g0n3 | 23:43 | |
| *** igor_ has joined #openstack-trove | 23:49 | |
| *** igor_ has quit IRC | 23:54 | |
| *** michael-yu has quit IRC | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!