amcrn | cp16net demorris: just replied to the configuration-group mailing-list thread, fyi. | 00:05 |
---|---|---|
*** grapex has quit IRC | 00:05 | |
openstackgerrit | Khyati Sheth proposed a change to openstack/trove: Mask Database user's password in trove api log https://review.openstack.org/58858 | 00:06 |
*** dougshelley66 has quit IRC | 00:15 | |
*** dougshelley66 has joined #openstack-trove | 00:24 | |
*** openstackgerrit has quit IRC | 00:24 | |
*** openstackgerrit has joined #openstack-trove | 00:24 | |
*** reed has quit IRC | 00:28 | |
*** dougshelley66 has quit IRC | 00:29 | |
openstackgerrit | Khyati Sheth proposed a change to openstack/trove: Mask Database user's password in trove api log https://review.openstack.org/58858 | 00:30 |
*** demorris has quit IRC | 00:31 | |
*** vipul is now known as vipul-away | 00:35 | |
*** vipul-away is now known as vipul | 00:35 | |
*** vipul is now known as vipul-away | 00:51 | |
*** vipul-away is now known as vipul | 00:53 | |
*** yogesh has joined #openstack-trove | 01:02 | |
*** haomaiwang has joined #openstack-trove | 01:09 | |
*** plodronio has quit IRC | 01:09 | |
*** haomaiwang has quit IRC | 01:14 | |
*** ashestakov has joined #openstack-trove | 01:17 | |
*** ashestakov has quit IRC | 01:22 | |
*** yogesh has quit IRC | 01:46 | |
openstackgerrit | Steve Leon proposed a change to openstack/trove: Instance details view shows hostname (if it has it) or IP https://review.openstack.org/61910 | 01:53 |
*** greghill has joined #openstack-trove | 02:06 | |
*** erkules_ has joined #openstack-trove | 02:22 | |
*** erkules has quit IRC | 02:25 | |
*** reed has joined #openstack-trove | 02:37 | |
*** achampion has joined #openstack-trove | 02:43 | |
*** plodronio has joined #openstack-trove | 02:47 | |
*** plodronio has left #openstack-trove | 02:48 | |
*** amcrn has quit IRC | 02:52 | |
*** SushilKM has joined #openstack-trove | 02:57 | |
*** haomaiwang has joined #openstack-trove | 03:11 | |
*** haomaiwang has quit IRC | 03:16 | |
SushilKM | hey slicknik, hub_cap, vipul kindly review https://review.openstack.org/#/c/58834/ this updates troveclient readme to latest help and also updates typos in shell.py, this was earlier -1d for troveclient bug | 03:26 |
*** greghill has quit IRC | 03:37 | |
openstackgerrit | Sushil Kumar proposed a change to openstack/trove: Adds support for running PyPy,py33 tests with tox https://review.openstack.org/61917 | 04:06 |
*** haomaiwang has joined #openstack-trove | 04:11 | |
SushilKM | needed help for re-running redwarf on https://review.openstack.org/#/c/61853/ it failed due to unexpected reasons :) | 04:11 |
*** SushilKM has quit IRC | 04:15 | |
*** SushilKM has joined #openstack-trove | 04:17 | |
*** jcooley_ has joined #openstack-trove | 04:17 | |
*** SushilKM has quit IRC | 04:20 | |
*** SushilKM has joined #openstack-trove | 04:21 | |
*** SushilKM has quit IRC | 04:25 | |
*** jasonb365 has joined #openstack-trove | 04:36 | |
*** haomaiwang has quit IRC | 04:43 | |
*** haomaiwa_ has joined #openstack-trove | 04:44 | |
*** haomaiwa_ has quit IRC | 04:47 | |
*** haomaiwang has joined #openstack-trove | 04:47 | |
*** abramley has quit IRC | 04:57 | |
*** jcooley_ has quit IRC | 05:06 | |
*** jcooley_ has joined #openstack-trove | 05:15 | |
*** AndroUser2 has joined #openstack-trove | 05:20 | |
*** SergeyLukjanov has joined #openstack-trove | 05:27 | |
*** shalini has joined #openstack-trove | 05:33 | |
*** shalini has quit IRC | 05:34 | |
*** reed has quit IRC | 05:36 | |
*** erkules_ is now known as erkules | 05:45 | |
*** jcooley_ has quit IRC | 05:54 | |
*** jcooley_ has joined #openstack-trove | 05:54 | |
*** jcooley_ has quit IRC | 05:59 | |
*** jaishanker has joined #openstack-trove | 05:59 | |
*** jcooley_ has joined #openstack-trove | 06:02 | |
*** jcooley_ has quit IRC | 06:04 | |
*** jcooley_ has joined #openstack-trove | 06:04 | |
*** jaishanker_ has joined #openstack-trove | 06:11 | |
*** ashestakov has joined #openstack-trove | 06:14 | |
*** jaishanker has quit IRC | 06:14 | |
*** ashestakov has quit IRC | 06:14 | |
*** jcooley_ has quit IRC | 06:19 | |
*** denis_makogon has joined #openstack-trove | 06:20 | |
*** jasonb365 has quit IRC | 06:22 | |
*** jaishanker_ has quit IRC | 06:26 | |
*** SushilKM has joined #openstack-trove | 06:39 | |
*** yogesh has joined #openstack-trove | 06:52 | |
*** yogesh has quit IRC | 06:57 | |
*** SergeyLukjanov is now known as _SergeyLukjanov | 07:05 | |
*** _SergeyLukjanov has quit IRC | 07:06 | |
*** yogesh has joined #openstack-trove | 07:06 | |
*** AndroUser2 has quit IRC | 07:11 | |
*** SergeyLukjanov has joined #openstack-trove | 07:19 | |
*** yogesh has quit IRC | 07:41 | |
*** SergeyLukjanov is now known as _SergeyLukjanov | 07:44 | |
*** _SergeyLukjanov has quit IRC | 07:45 | |
*** flaper87|afk is now known as flaper87 | 08:06 | |
*** yogesh has joined #openstack-trove | 08:10 | |
*** SergeyLukjanov has joined #openstack-trove | 08:12 | |
*** denis_makogon has quit IRC | 08:25 | |
*** rongze has joined #openstack-trove | 08:29 | |
*** yogesh has quit IRC | 08:42 | |
*** yogesh has joined #openstack-trove | 08:46 | |
*** yogesh has quit IRC | 08:46 | |
*** yogesh_ has joined #openstack-trove | 08:48 | |
*** nosnos has joined #openstack-trove | 08:55 | |
*** yogesh has joined #openstack-trove | 08:55 | |
*** yogesh_ has quit IRC | 08:56 | |
openstackgerrit | Jenkins proposed a change to openstack/trove: Updated from global requirements https://review.openstack.org/61935 | 08:56 |
*** rongze has quit IRC | 09:05 | |
*** yogesh has quit IRC | 09:16 | |
*** yogesh has joined #openstack-trove | 09:21 | |
*** SergeyLukjanov has quit IRC | 09:22 | |
*** rongze has joined #openstack-trove | 09:34 | |
*** yogesh has quit IRC | 09:41 | |
*** yogesh has joined #openstack-trove | 09:42 | |
*** yogesh has quit IRC | 09:45 | |
*** yogesh has joined #openstack-trove | 09:46 | |
openstackgerrit | Sushil Kumar proposed a change to openstack/trove-integration: Removes log generation parameters from EXTRA_OPTS https://review.openstack.org/61948 | 09:49 |
*** nosnos has quit IRC | 09:51 | |
*** SergeyLukjanov has joined #openstack-trove | 10:10 | |
*** yogesh has quit IRC | 10:14 | |
*** yogesh has joined #openstack-trove | 10:15 | |
*** flaper87 is now known as flaper87|afk | 10:33 | |
*** yogesh has quit IRC | 10:34 | |
*** yogesh has joined #openstack-trove | 10:34 | |
*** yogesh has quit IRC | 10:39 | |
*** rongze has quit IRC | 11:06 | |
*** rongze has joined #openstack-trove | 11:38 | |
openstackgerrit | Denis M. proposed a change to openstack/trove: Block delete instance while buckup https://review.openstack.org/61969 | 11:41 |
*** yogesh has joined #openstack-trove | 11:45 | |
*** rongze has quit IRC | 11:49 | |
*** yogesh has quit IRC | 11:49 | |
*** rongze has joined #openstack-trove | 12:15 | |
*** SergeyLukjanov is now known as _SergeyLukjanov | 12:24 | |
*** _SergeyLukjanov has quit IRC | 12:25 | |
*** dougshelley66 has joined #openstack-trove | 12:26 | |
*** SergeyLukjanov has joined #openstack-trove | 12:33 | |
*** abramley has joined #openstack-trove | 12:52 | |
*** dmakogon_ is now known as denis_makogon | 13:02 | |
*** pdmars has joined #openstack-trove | 13:05 | |
*** OpenStack1 has joined #openstack-trove | 13:10 | |
openstackgerrit | Denis M. proposed a change to openstack/trove: Block delete instance while buckup https://review.openstack.org/61969 | 13:17 |
openstackgerrit | Ionut Artarisi proposed a change to openstack/trove: add sql_connection option to the sample config for guestagent https://review.openstack.org/61989 | 13:20 |
*** shakayumi has joined #openstack-trove | 13:43 | |
*** OpenStack1 has quit IRC | 13:51 | |
*** PradeepChandani has quit IRC | 13:57 | |
*** rongze has quit IRC | 13:59 | |
*** radez_g0n3 is now known as radez | 13:59 | |
*** robertmyers has joined #openstack-trove | 14:18 | |
*** SushilKM has quit IRC | 14:20 | |
*** robertmyers has quit IRC | 14:20 | |
*** robertmyers has joined #openstack-trove | 14:21 | |
*** OpenStack1 has joined #openstack-trove | 14:21 | |
*** russellb is now known as rustlebee | 14:25 | |
*** flaper87|afk is now known as flaper87 | 14:26 | |
*** glucas has joined #openstack-trove | 14:35 | |
*** rongze has joined #openstack-trove | 14:44 | |
*** rnirmal has joined #openstack-trove | 14:44 | |
*** abramley_ has joined #openstack-trove | 14:46 | |
*** OpenStack1 has quit IRC | 14:46 | |
*** abramley has quit IRC | 14:48 | |
*** abramley_ is now known as abramley | 14:48 | |
*** demorris has joined #openstack-trove | 14:48 | |
*** shakayumi has quit IRC | 14:49 | |
*** Flying_Bond has joined #openstack-trove | 14:52 | |
*** Barker has joined #openstack-trove | 14:54 | |
*** plodronio has joined #openstack-trove | 14:56 | |
*** mrsnivvel has quit IRC | 14:56 | |
*** vgnbkr has joined #openstack-trove | 14:57 | |
*** jcooley_ has joined #openstack-trove | 15:00 | |
*** jcru has joined #openstack-trove | 15:00 | |
*** kevinconway has joined #openstack-trove | 15:03 | |
*** shakayumi has joined #openstack-trove | 15:03 | |
*** shakayumi has quit IRC | 15:08 | |
*** shakayumi has joined #openstack-trove | 15:10 | |
*** rongze has quit IRC | 15:11 | |
*** Flying_Bond has quit IRC | 15:16 | |
*** Flying_Bond has joined #openstack-trove | 15:17 | |
*** datsun180b has joined #openstack-trove | 15:26 | |
*** jasonb365 has joined #openstack-trove | 15:26 | |
*** grapex has joined #openstack-trove | 15:28 | |
*** greghill has joined #openstack-trove | 15:29 | |
*** amytron has joined #openstack-trove | 15:30 | |
*** Sushil_GL has joined #openstack-trove | 15:31 | |
*** Sushil_GL has quit IRC | 15:31 | |
*** rwsu has joined #openstack-trove | 15:31 | |
*** Sushil_GL has joined #openstack-trove | 15:31 | |
*** SushilGL has joined #openstack-trove | 15:36 | |
*** jcooley_ has quit IRC | 15:37 | |
*** SushilKM has joined #openstack-trove | 15:37 | |
*** jcooley_ has joined #openstack-trove | 15:38 | |
*** rongze has joined #openstack-trove | 15:39 | |
*** Sushil_GL has quit IRC | 15:40 | |
SushilKM | hi hub_cap | 15:40 |
SushilKM | ur review required on https://review.openstack.org/#/c/58834/ | 15:40 |
SushilKM | hi slicknik, vipul, hub_cap, denis needed review on https://review.openstack.org/#/c/61948/ :) | 15:42 |
*** yidclare has quit IRC | 15:43 | |
*** jcooley_ has quit IRC | 15:43 | |
SushilKM | thats for u hub_cap http://lonbronsonband.com/images/Friday-2.gif | 15:44 |
*** OpenStack1 has joined #openstack-trove | 15:49 | |
*** rnirmal_ has joined #openstack-trove | 16:02 | |
*** rnirmal has quit IRC | 16:02 | |
*** rnirmal_ is now known as rnirmal | 16:02 | |
*** shakayumi has quit IRC | 16:08 | |
*** jcooley_ has joined #openstack-trove | 16:09 | |
*** SnowDust has joined #openstack-trove | 16:11 | |
*** rongze has quit IRC | 16:14 | |
*** Flying_Bond has quit IRC | 16:15 | |
*** Flying_Bond has joined #openstack-trove | 16:20 | |
*** rongze has joined #openstack-trove | 16:21 | |
*** jcooley_ has quit IRC | 16:21 | |
*** jcooley_ has joined #openstack-trove | 16:21 | |
*** jcooley_ has quit IRC | 16:25 | |
*** OpenStack1 has quit IRC | 16:28 | |
*** Flying_Bond has quit IRC | 16:37 | |
*** openstackgerrit has quit IRC | 16:37 | |
*** juice has quit IRC | 16:37 | |
*** extrovert has quit IRC | 16:37 | |
dougshelley66 | r0utemap | 16:38 |
*** OpenStack1 has joined #openstack-trove | 16:38 | |
*** 17WAAKZAN has joined #openstack-trove | 16:38 | |
*** Flying_Bond has joined #openstack-trove | 16:38 | |
*** openstackgerrit has joined #openstack-trove | 16:38 | |
*** juice has joined #openstack-trove | 16:38 | |
*** extrovert has joined #openstack-trove | 16:38 | |
*** haomaiwang has quit IRC | 16:39 | |
*** SushilKM has quit IRC | 16:40 | |
*** SergeyLukjanov has quit IRC | 16:43 | |
*** haomaiwang has joined #openstack-trove | 16:44 | |
*** OpenStack1 has quit IRC | 16:47 | |
*** juice- has joined #openstack-trove | 16:49 | |
*** SushilGL has quit IRC | 16:49 | |
*** 17WAAKZAN has quit IRC | 16:49 | |
*** Flying_Bond has quit IRC | 16:49 | |
*** openstackgerrit has quit IRC | 16:49 | |
*** juice has quit IRC | 16:49 | |
*** extrovert has quit IRC | 16:49 | |
*** juice- is now known as juice | 16:49 | |
*** Flying_Bond has joined #openstack-trove | 16:51 | |
*** SushilKM has joined #openstack-trove | 16:51 | |
*** jcooley_ has joined #openstack-trove | 16:55 | |
cp16net | SushilKM: thats an awesome dancing garfield | 17:02 |
SnowDust | whats that cp16net ? | 17:02 |
cp16net | http://lonbronsonband.com/images/Friday-2.gif | 17:02 |
cp16net | heh | 17:02 |
SushilKM | btw noone seems here, big silence | 17:04 |
SnowDust | cp16net .. where is it pointing to ? | 17:05 |
*** SushilKM has quit IRC | 17:08 | |
SnowDust | SushilKM :) lost his cool .. when everything was so cold :D and quit | 17:09 |
SnowDust | lets see .. if someone speaks in the silence | 17:09 |
*** haomaiwang has quit IRC | 17:11 | |
cp16net | yeah everyone must be hung over :-P | 17:12 |
SnowDust | if anyone interested we are discussing the remaining to be done to implement tempest for trove at #openstack-ds-trove | 17:13 |
SnowDust | keeping it noise free ... here :) | 17:13 |
SnowDust | all interested please join there | 17:13 |
kevinconway | SnowDust: that seems like you should have that conversation in here | 17:14 |
kevinconway | that way channel logging can record it | 17:14 |
SnowDust | ok .. | 17:14 |
SnowDust | lets do that no issues | 17:14 |
SnowDust | am bringing the guys here | 17:14 |
greghill | since the bot didn't seem to announce it - https://review.openstack.org/#/c/62039/ for the datastore backwards compatibility bug. review! DO IT NOW!!1 | 17:15 |
*** SushilGL has joined #openstack-trove | 17:20 | |
SnowDust | hi all | 17:21 |
SnowDust | diakunchikov | 17:21 |
SnowDust | Flying_bond | 17:21 |
hub_cap | hi back to this room? | 17:21 |
SnowDust | Lets restart the tempest progress | 17:21 |
SnowDust | yes .. | 17:21 |
SnowDust | kevinconway is missed out :) | 17:21 |
hub_cap | <3 | 17:21 |
hub_cap | lets definitely not move rooms again :) | 17:21 |
SnowDust | sure hub_cap | 17:21 |
*** openstackgerrit has joined #openstack-trove | 17:21 | |
hub_cap | it happened for the horizon stuff too and its hard to track | 17:22 |
hub_cap | i had no idea what was goin on w it hehe | 17:22 |
diakunchikov | I'm here ^) | 17:22 |
kevinconway | hub_cap: well doh. if i had known you were cool with convos in another room i wouldn't have said anything | 17:22 |
kevinconway | i figured you wanted everything logged | 17:22 |
SnowDust | we switched .. and then thought to invite more .. and lastly came back with our <3 here ! | 17:22 |
*** SergeyLukjanov has joined #openstack-trove | 17:23 | |
hub_cap | hehe | 17:23 |
hub_cap | kevinconway: i _want_ them all here | 17:23 |
SnowDust | atleast in a week i saw hub_cap in public convos LOL ! | 17:23 |
hub_cap | i said "lets def not move rooms again" kevinconway, i think maybe u misread me :p | 17:23 |
SnowDust | ok lets begin | 17:23 |
hub_cap | do it | 17:23 |
SnowDust | two part of the work | 17:23 |
Flying_Bond | Hi all | 17:24 |
SnowDust | 1. cli tests ( all wrote ) https://review.openstack.org/#/c/61937/ | 17:24 |
SnowDust | 2. api tests ( in progress) | 17:24 |
SnowDust | now .. we need additional overhauls to get trove in tempest | 17:24 |
SnowDust | which are | 17:24 |
SnowDust | 1. devstack changes | 17:24 |
diakunchikov | 2.api tests https://blueprints.launchpad.net/tempest/+spec/add-trove-api-tests and https://review.openstack.org/#/c/60254/ | 17:25 |
SnowDust | 2. configuration change in tempest | 17:25 |
SnowDust | diakunchikov: thanks ! | 17:25 |
diakunchikov | what do u mean in configuration change in tempest | 17:26 |
*** OpenStack1 has joined #openstack-trove | 17:26 | |
*** amcrn has joined #openstack-trove | 17:27 | |
SnowDust | i meant this : <dkranz> Flying_Bond: You need to add something for trove in the feature_enabled section of the tempest config | 17:27 |
hub_cap | and we have to make sure we have a valid image in trove/glance | 17:27 |
hub_cap | thats the work that slicknik is doing ^ ^ | 17:27 |
hub_cap | its in a blueprint somewhere | 17:28 |
*** SushilKM has joined #openstack-trove | 17:28 | |
SnowDust | yes .. thats good | 17:28 |
SnowDust | so we are separate from each others progress which is the best part :) | 17:28 |
SnowDust | anything .. that is left out ? hub_cap ? | 17:29 |
SnowDust | as it seems all the necessary breakup is being worked on ... | 17:29 |
*** Flying_Bond has quit IRC | 17:30 | |
SnowDust | anyone to ask or share ? | 17:30 |
hub_cap | nope thats all of it | 17:30 |
hub_cap | now everyone get to work!!!!!!!!!!!!!!!! | 17:31 |
hub_cap | hehehehe | 17:31 |
*** Flying_Bond has joined #openstack-trove | 17:31 | |
SnowDust | yes .. sure .. | 17:31 |
SnowDust | will get it to level 1 very soon :) | 17:31 |
hub_cap | SnowDust: can u create a master blueprint in trove and make sure all the "pieces" that we talked about are dependencies on it? | 17:31 |
hub_cap | sorry, a master "tempest test" blueprint | 17:31 |
hub_cap | a epic :) | 17:31 |
SnowDust | ok .. will take the ownership of it .. its in my <3 now .. and diakunchikov / Flying_bond are supporting it in awesome way | 17:32 |
hub_cap | thx SnowDust | 17:33 |
openstackgerrit | Sushil Kumar proposed a change to openstack/trove-integration: Fixes typos in project files https://review.openstack.org/62050 | 17:33 |
SushilKM | hey hub_cap need ur review on this one, https://review.openstack.org/#/c/58834/ | 17:35 |
*** OpenStack1 has quit IRC | 17:36 | |
*** freyes has joined #openstack-trove | 17:36 | |
*** Flying_Bond has joined #openstack-trove | 17:37 | |
*** Flying_Bond has joined #openstack-trove | 17:39 | |
*** Flying_Bond has quit IRC | 17:40 | |
*** SnowDust has quit IRC | 17:40 | |
*** freyes has quit IRC | 17:41 | |
*** Flying_Bond has joined #openstack-trove | 17:41 | |
*** Flying_Bond has quit IRC | 17:41 | |
*** amytron has quit IRC | 17:42 | |
*** Sushil_GL has joined #openstack-trove | 17:42 | |
*** SushilKM has quit IRC | 17:43 | |
*** reed has joined #openstack-trove | 17:43 | |
hub_cap | does SushilKM just dissapear right after he speaks? lol | 17:44 |
*** Flying_Bond has joined #openstack-trove | 17:45 | |
*** SergeyLukjanov_ has joined #openstack-trove | 17:48 | |
*** SergeyLukjanov has quit IRC | 17:48 | |
*** OpenStack1 has joined #openstack-trove | 17:50 | |
*** SnowDust has joined #openstack-trove | 17:53 | |
hub_cap | SnowDust: can u shoot me a link to it when u get it all set up so i can check it out | 17:54 |
SnowDust | sure .. doing it | 17:59 |
*** demorris_ has joined #openstack-trove | 17:59 | |
openstackgerrit | Sushil Kumar proposed a change to openstack/python-troveclient: Updates README with new trove help options https://review.openstack.org/58834 | 18:00 |
*** demorris has quit IRC | 18:02 | |
*** demorris_ is now known as demorris | 18:02 | |
Sushil_GL | Hey hub_cap vipul slicknik, updated the commit message .... :) | 18:03 |
*** freyes has joined #openstack-trove | 18:04 | |
*** harlowja has quit IRC | 18:05 | |
*** SushilKM has joined #openstack-trove | 18:07 | |
*** SushilGL has quit IRC | 18:08 | |
*** Sushil_GL has quit IRC | 18:08 | |
*** SushilKM has quit IRC | 18:09 | |
*** SushilKM has joined #openstack-trove | 18:09 | |
SushilKM | Hey hub_cap if u can review this one too https://review.openstack.org/61948 | 18:12 |
amcrn | denis_makogon: is ashestakov out for the day? | 18:14 |
*** kevinconway has quit IRC | 18:15 | |
*** freyes has quit IRC | 18:16 | |
*** amytron has joined #openstack-trove | 18:17 | |
*** harlowja has joined #openstack-trove | 18:24 | |
openstackgerrit | Steve Leon proposed a change to openstack/trove: Instance details view shows hostname (if it has it) or IP https://review.openstack.org/61910 | 18:25 |
*** yidclare has joined #openstack-trove | 18:27 | |
*** yogesh has joined #openstack-trove | 18:31 | |
*** rwsu has quit IRC | 18:32 | |
*** OpenStack1 has quit IRC | 18:34 | |
*** SushilKM has quit IRC | 18:38 | |
*** rwsu has joined #openstack-trove | 18:40 | |
*** SushilKM has joined #openstack-trove | 18:45 | |
*** abramley has quit IRC | 18:54 | |
*** abramley has joined #openstack-trove | 18:55 | |
*** OpenStack1 has joined #openstack-trove | 18:59 | |
*** OpenStack1 has quit IRC | 19:03 | |
*** Flying_Bond has quit IRC | 19:08 | |
*** kevinconway has joined #openstack-trove | 19:08 | |
robertmyers | SlickNik: hub_cap: would like to get your reviews on https://review.openstack.org/#/c/56702/ | 19:12 |
robertmyers | hub_cap: and https://review.openstack.org/#/c/59283/ | 19:13 |
*** kanzaros has joined #openstack-trove | 19:14 | |
SlickNik | robertmyers: sure, will look in about an hour'ish. | 19:17 |
robertmyers | SlickNik: thanks! | 19:18 |
*** jmontemayor has joined #openstack-trove | 19:18 | |
*** rongze has quit IRC | 19:20 | |
openstackgerrit | Greg Hill proposed a change to openstack/trove: add support for working with pre-datastore instances https://review.openstack.org/62039 | 19:23 |
cp16net | amcrn: i replied to your concerns wrt validation rules | 19:30 |
cp16net | with some more concerns.. :) | 19:30 |
amcrn | yeah, i'm not particularly happy with the workaround i presented, but | 19:30 |
amcrn | "if a provider creates a datastore of "mysql" with two versions, "5.5" and "5.6", both versions must share the same manager, meaning there is no means of having separate validation-rules for the configuration-groups." | 19:31 |
amcrn | that's a big problem | 19:31 |
hub_cap | i think we hoped / assumed people would make mysql5.5 a datastore | 19:31 |
hub_cap | since the 5.X's are so drastically different | 19:31 |
cp16net | yeah i think thats the draw back of having the DS stuff so general | 19:31 |
hub_cap | yup.. its configurable, but its not recommended ;) | 19:32 |
amcrn | lol | 19:32 |
amcrn | i don't think we should lend people enough rope to hang themselves though | 19:32 |
hub_cap | exactly | 19:32 |
hub_cap | i was writing something like that | 19:32 |
cp16net | yeah the more i think about it you should really make it mysql5.[1,5,6] | 19:32 |
hub_cap | so there comes a point where we have to "draw a line in the sand" | 19:32 |
hub_cap | and this is kinda that right? like we should help make a decision somehow | 19:33 |
amcrn | if we think about this in the context of migrations, you'll need version to version migration "managers" anyway | 19:33 |
hub_cap | but how can we really? | 19:33 |
cp16net | and then the wind blows the sand around | 19:33 |
hub_cap | lol cp16net | 19:33 |
cp16net | yeah version to version would not work if you are upgrading from 5.1 to 5.5 | 19:34 |
amcrn | if the manager concept is moved to the datastore-version (from the datastore), this largely solves the problem | 19:34 |
amcrn | then each version can choose to have a different manager, which in turn means it can have a different set of validation-rules | 19:34 |
cp16net | but if you are saying that we can have validation rules for versions as well as types | 19:35 |
amcrn | well, right now you have validation-rules per manager | 19:35 |
cp16net | depending on how you create a CG | 19:35 |
cp16net | we would need to merge those in the code | 19:35 |
amcrn | that would remain the same, the only change would be to permit a different manager per version instead of per type | 19:36 |
hub_cap | but do we need to solve this for all ds' for one bastard one amcrn? :P | 19:36 |
cp16net | but which to you apply if they override each other | 19:36 |
cp16net | heh | 19:36 |
hub_cap | do we have to deal w/ this with other datastores? like would people want to run a specific version of cassandra thats _not_ latest (i assume so?) | 19:36 |
amcrn | cp16net: sorry, let me re-explain. kill the whole <type>-<version> multiple lookup idea | 19:36 |
cp16net | ok | 19:36 |
amcrn | keep it as-is, except, move the manager column from the datastore table to the datastore_version table | 19:37 |
cp16net | hub_cap: or redis maybe? (i dont know) | 19:37 |
cp16net | so instances are tied to a version which should ahve a manager | 19:37 |
hub_cap | amcrn: but then if we use it like mysql5.5, with 5.5.32 or whatever as teh version, i have to keep putting that manager in that version? | 19:37 |
cp16net | then the CG uses the manager field to know what to validate for | 19:38 |
amcrn | well, we can work around the tediousness of setting the values up via trove-manage, but let's first vet whether the idea works | 19:38 |
hub_cap | well the theory works | 19:38 |
amcrn | cp16net: correct | 19:38 |
cp16net | i mean *anything* could work :-P | 19:39 |
amcrn | alright, now if we try and anticipate the datastore migration scenario | 19:39 |
amcrn | it's *possible* that a datastore has a different migration strategy from version 1.x to 1.y, and a different one for 1.x to 1.z | 19:39 |
amcrn | depending on their versioning scheme, whether they accidentally released a version with an incompatible change and reverted days later, etc. | 19:40 |
amcrn | so in short, migrations will need a manager on a version to version basis, not type to type, because the level of granularity required will vary | 19:40 |
amcrn | granted certain migration-managers will be shareable | 19:40 |
amcrn | so from a configuration-group scenario, there has to be a way to convert or validate or clone during a migration | 19:41 |
amcrn | e.g. if i have an instance w/ a configuration-group against mysql-5.5, and i do a migration to mysql-5.7 in 2014, how does the validation work for the configuration | 19:42 |
amcrn | does the cloud provider explicitly set up a "compatibility" list of version-to-version ok's, or does each version have it's own validation-rules.json and during a migration they're cross-checked | 19:43 |
kevinconway | so i'm trying to catch up on this conversation. are you talking about configs or actual migrations of data ? | 19:43 |
amcrn | how does a user in general assert whether an existing configuration-group against mysql-5.5 is valid against 5.6? | 19:43 |
amcrn | kevinconway: configs, but i'm attempting to anticipate migrations, so we don't have to revisit at what granularity should validation-rules exist | 19:44 |
cp16net | http://img.pandawhale.com/post-22106-Cup-and-Ball-perfect-loop-gif-pOdK.gif | 19:44 |
kevinconway | i guess i'm confused about mapping compatibility between version of the same type | 19:45 |
kevinconway | if you can't guarantee a migration from one version to the next wouldn't those be, by definition, a new type? | 19:45 |
amcrn | it depends on whether there's a hard stance on what is a "datastore", is it a logical grouping that the provider chooses, or is it by definition a datastore of various versions that are all migratable? | 19:48 |
*** OpenStack1 has joined #openstack-trove | 19:48 | |
amcrn | nothing stops a datastore provider from adding a new configuration-parameter in a minor version, they merely aren't allowed to remove any (to be backwards compatible) | 19:49 |
amcrn | now you've got a situation in which a validation-rules set for the datastore is incorrect, because you'll either reject saying the new parameter isn't real, or you'll accept it on an older version that didn't support it | 19:50 |
kevinconway | amcrn: you're making assumptions about versioning schemes here though | 19:50 |
kevinconway | i think most sane products would use major.minor.patch, but we already have an obvious exception with mysql | 19:50 |
kevinconway | whether or not two versions of a product are compatible is totally separate from its version number | 19:51 |
amcrn | good point. so given your last statement, we can't guarantee that 2 versions under a single datastore are "compatible" | 19:52 |
kevinconway | i think it's the responsibility of the cloud provider to only place entries in a datastore version that they know are compatible | 19:53 |
kevinconway | otherwise they create a new datastore type | 19:53 |
SnowDust | hub_cap : updated SlickNic's trove-tempest blueprint with work items but rest i will be following with him to get updated | 19:53 |
SnowDust | its SlickNik oopzz | 19:53 |
kevinconway | i think we're trying to add features like config compat and data migrations that require an opinionated view of what a datastore type and datastore version are | 19:54 |
kevinconway | but at the same time keeping those metadata unopinionated | 19:54 |
amcrn | kevinconway: the tricky part will be documenting this in bold, explaining you shouldn't do things like "mysql" => "5.5", "5.6", even though the system will let you | 19:54 |
amcrn | which means, as good citizens, the redstack scripts and other artifacts should follow the known-good path | 19:55 |
amcrn | to avoid leading users down the wrong path | 19:55 |
cp16net | amcrn: yes i agree with that | 19:55 |
cp16net | i think thats why i thought it would be originally mysql - 5.1, 5.5 | 19:55 |
cp16net | which enlighted me that its a bad idea | 19:56 |
cp16net | after all these convos | 19:56 |
amcrn | one thing to point out though, is that a well known cloud provider has a flat datastore naming scheme, which means implicitly each version has it's own validation | 19:56 |
amcrn | i.e. instead of type + version, it's a single label | 19:57 |
*** kanzaros has quit IRC | 19:57 | |
kevinconway | amcrn: that's what i thought we wanted when i was suggesting to use glance image names instead of new metadata | 19:57 |
amcrn | so we should be aware we're going against the grain here by choosing validation against a grouping/type | 19:57 |
kevinconway | a flat space that is | 19:57 |
*** OpenStack1 has quit IRC | 19:58 | |
*** kanzaros has joined #openstack-trove | 19:58 | |
kevinconway | but i think the versioning scheme we have could be beneficial when it comes to doing update/migrations | 19:59 |
amcrn | agreed | 19:59 |
amcrn | so i think we're all in consensus on how we should guide users on setting up their datastore heirarchies | 20:00 |
*** OpenStack1 has joined #openstack-trove | 20:01 | |
*** kanzaros has quit IRC | 20:01 | |
amcrn | but i still don't see the harm in moving 'manager' to datastore-version. the only downside is that you have an extra argument to pass to 'trove-manage', but you buy the ability to have different validations per version if you so choose | 20:01 |
*** OpenStack1 has quit IRC | 20:01 | |
amcrn | by default the same value can be passed to each version, so it will behave the same as it is now | 20:01 |
amcrn | have to jump to a meeting, will come back later | 20:02 |
*** kanzaros has joined #openstack-trove | 20:05 | |
*** kanzaros has quit IRC | 20:06 | |
*** kanzaros has joined #openstack-trove | 20:06 | |
*** harlowja has quit IRC | 20:07 | |
*** SnowDust has quit IRC | 20:13 | |
greghill | DOCS!!!! I thought that got sorted out | 20:13 |
kevinconway | greghill: just use the old trove motto: "If it doesn't do right the first time just keep doing it again until it does." | 20:15 |
cp16net | hub_cap: what do you mean "add the test of the scripts cowboy!" | 20:15 |
cp16net | #link https://review.openstack.org/#/c/54225/ | 20:16 |
hub_cap | cp16net: that makes no sense | 20:23 |
hub_cap | i think i passted something wronge | 20:23 |
hub_cap | wrongie | 20:23 |
hub_cap | i meant just update he other bin/ scripts | 20:23 |
hub_cap | LOL | 20:23 |
hub_cap | sweet just got done talkin w/ a structural engineer about our remodel | 20:24 |
cp16net | ok cool | 20:24 |
cp16net | :-P | 20:24 |
hub_cap | he says we arent doing anything that requires special headers | 20:24 |
*** jcooley_ has quit IRC | 20:24 | |
hub_cap | we wont need a engineer approval horray! | 20:24 |
hub_cap | and he was good buddies w/ the guy who owned the house HAH | 20:24 |
hub_cap | also cp16net fix that cmmit msg | 20:25 |
hub_cap | i agree w amcrn | 20:25 |
cp16net | yeah i'm workin on it | 20:25 |
cp16net | true | 20:25 |
hub_cap | but now i must go to lunch, says wife :) | 20:25 |
hub_cap | amcrn: u know acme and semifreddi bread companies? | 20:25 |
demorris | hey so I just caught up on the discussion about configs and datastore types | 20:26 |
hub_cap | http://www.acmebread.com/bread | 20:26 |
demorris | did we land somewhere, it was not clear | 20:26 |
datsun180b | hub_cap: i'm confused why none of this bread features rocket skates or flying suits | 20:28 |
demorris | one way we can simplify the config stuff is to limit what it can do in the first rev | 20:28 |
datsun180b | or gigantic catapults or slingshots | 20:28 |
openstackgerrit | Craig Vyvial proposed a change to openstack/trove: make the bin scripts called with main() https://review.openstack.org/54225 | 20:28 |
cp16net | mo betta | 20:28 |
demorris | we could just say, you can't use configurations across db types | 20:29 |
*** yogesh has quit IRC | 20:30 | |
*** rongze has joined #openstack-trove | 20:31 | |
*** SushilGL has joined #openstack-trove | 20:32 | |
*** SushilKM has quit IRC | 20:33 | |
*** SushilGL has quit IRC | 20:33 | |
*** SushilKM has joined #openstack-trove | 20:33 | |
*** rongze has quit IRC | 20:36 | |
*** jcooley_ has joined #openstack-trove | 20:37 | |
demorris | hub_cap: yt? | 20:38 |
demorris | I am wondering if we maybe need to put some restrictions into the types / versions code | 20:38 |
cp16net | demorris: i agree we should not try to emcompass everything in v1 of CG | 20:38 |
demorris | I was originally thinking that the default way to use this would be something like Type (MySQL 5.5) and Versions (X.X.X) | 20:38 |
demorris | but now I am thinking that does not make sense | 20:38 |
*** jcooley_ has quit IRC | 20:39 | |
kevinconway | demorris: i think amcrn and i agreed earlier that we need to clearly define and restrict was is a type and what is a version | 20:39 |
kevinconway | i'm of the opinion that anything the cloud provider knows is compatible is a version of the same type otherwise it needs a new type defined | 20:40 |
hub_cap | ++ | 20:40 |
hub_cap | demorris: not really here, bout to eat lunch | 20:40 |
hub_cap | but i have a pageup key demorris so ask away | 20:41 |
demorris | yeah, I think to start, one restriction needs to be that a type is just the db type (MySQL) | 20:41 |
demorris | and versions is a major version, X.X | 20:42 |
kevinconway | i think that's too general | 20:42 |
kevinconway | that would put mysql 5.1 and 5.5 in the same pool | 20:42 |
*** SushilGL has joined #openstack-trove | 20:42 | |
demorris | because? | 20:42 |
cp16net | i think the fall out of doing that would be that we need another table for the patch version that you suport then for each version | 20:43 |
kevinconway | i would rather see 5.1 as the type and 5.1.1, 5.1.2 as the versions | 20:43 |
demorris | what does the table currently contain? | 20:44 |
cp16net | other wise you will fall into the current idea of not knowing what patch version is currently installed and being used on the instances | 20:44 |
kevinconway | demorris: i don't understand the question | 20:44 |
cp16net | #link https://github.com/openstack/trove/blob/master/trove/db/sqlalchemy/migrate_repo/versions/016_add_datastore_type.py | 20:45 |
demorris | you mentioned you would need another table | 20:45 |
demorris | so I wanted to know what the current table has in it and why you would need another table | 20:45 |
kevinconway | i think he's talking about the table(s) you would need to create compatibility matrices | 20:45 |
hub_cap | versions also imply "upgradeability" | 20:45 |
kevinconway | because if 5.1 and 5.5 are just mysql versions | 20:45 |
kevinconway | then you need to mark them as super incompatible some how | 20:45 |
kevinconway | i'm looking at it from the perspective that anything that is a version of the same type should be compatible from both a config and data migration standpoint | 20:46 |
kevinconway | if it breaks one of those then it should be a new type | 20:46 |
demorris | doenst a version id just point to a package so if it was 5.5 that would actually be some 5.5.X version | 20:46 |
*** SushilKM has quit IRC | 20:47 | |
kevinconway | demorris: version id and package are totally separate | 20:47 |
kevinconway | i can have TYPE: mysql VERSION: 5.5 PACKAGE: redid-server if i wanted | 20:47 |
kevinconway | *redis | 20:47 |
demorris | well thats silly, why would you allow that | 20:47 |
kevinconway | well nobody sane would do that to their users | 20:48 |
kevinconway | or themselves for that matter | 20:48 |
kevinconway | it's just possible | 20:48 |
kevinconway | but that's kind of what i keep trying to say. we made datastore types and versions VERY non-opinionated. | 20:49 |
kevinconway | i think we need to opinionated them to support some of the features we want, though. | 20:49 |
kevinconway | man, this spell check is killing me | 20:49 |
demorris | yeah, its making it very hard to build on | 20:49 |
demorris | near impossible to build on | 20:50 |
*** radez is now known as radez_g0n3 | 20:50 | |
demorris | too many what if scenarios | 20:50 |
kevinconway | and it's not just config edits, we have to think about migrations/updates too | 20:50 |
openstackgerrit | Craig Vyvial proposed a change to openstack/trove: make the bin scripts called with main() https://review.openstack.org/54225 | 20:54 |
*** OpenStack1 has joined #openstack-trove | 20:55 | |
demorris | kevinconway: right | 20:55 |
demorris | so curious how we get to resolution on this | 20:55 |
cp16net | well you could put PACKAGES: xtra-backup, mysql5.1, my-funny-agent, cpython, puppet | 20:55 |
*** harlowja has joined #openstack-trove | 20:56 | |
cp16net | and it would install all those packages in the prepare | 20:56 |
cp16net | just an example of possiblities | 20:56 |
demorris | packages is part of the versions table, and assuming it installs the latest | 20:56 |
kevinconway | i like PACKAGES: mysql5.1, nsa-prism | 20:56 |
cp16net | lol | 20:56 |
kevinconway | demorris: packages is whatever the cloud provider wants it to be | 20:57 |
cp16net | or... packages: mysql5.1==5.1.33 | 20:57 |
cp16net | bam you get that version | 20:57 |
kevinconway | just like datastore type and datastore version. it's a string field | 20:57 |
demorris | right, so lets say I want to support 5.1.63 and 5.1.69 versions of MySQL at major version 5.1 | 20:58 |
demorris | how would I set that up | 20:58 |
cp16net | its suppose to be the name of the package in the repo you are using. apt for debain/ubuntu or in yum for redhat | 20:58 |
cp16net | you could not separate that in a single version of 5.1 | 20:58 |
cp16net | BUT... | 20:58 |
cp16net | its only newly provisioned instances that this mattesr for | 20:59 |
demorris | then there is no point to ever have the minor version | 20:59 |
cp16net | if you want customers to be able to provision both of them then you could not do that | 20:59 |
demorris | unless I am missing something | 20:59 |
kevinconway | cp16net: right, so you could have a version of mysql5.1 where you flip the packages so new instances have the latest | 20:59 |
cp16net | sure | 20:59 |
*** glucas has quit IRC | 20:59 | |
cp16net | you could even mark it to a certain version at that point as well | 20:59 |
kevinconway | or make 5.1.63 a version of the TYPE: mysql5.1 | 20:59 |
kevinconway | or have a TYPE: MySQL5.6.63 and VERSION: WHATEVER_I_WANT | 21:00 |
cp16net | yeah | 21:00 |
cp16net | LOL true... | 21:00 |
demorris | yeah but that solves nothing | 21:00 |
demorris | there is no real point to do that | 21:00 |
hub_cap | thats not true that it solves nothing | 21:00 |
cp16net | maybe not with mysql. | 21:00 |
kevinconway | demorris: i agree | 21:00 |
hub_cap | it simplifies the code | 21:00 |
hub_cap | and it deliniates them as being _different_ | 21:01 |
demorris | if you just restrict to version is MySQL, Redis, MongoDB and version is x . x, then you can still be just as flexible | 21:01 |
cp16net | maybe something else could have that kind of setup | 21:01 |
cp16net | we dont know | 21:01 |
cp16net | we cant future proof everything... | 21:01 |
cp16net | :-P | 21:01 |
demorris | and for upgrades, the guest just needs to know what version it is at and check that against the latest package available in the list of supported versions to know if it needs to be upgraded | 21:01 |
demorris | that means though that you peg the code to only support the latest available version you have installed | 21:02 |
kevinconway | demorris: hang on, you said list of supported versions | 21:02 |
kevinconway | where does that come from? | 21:02 |
demorris | from the versions table | 21:02 |
demorris | there is a flag on if it is active or inactive | 21:02 |
kevinconway | but you're saying 5.1 and 5.5 are versions right? | 21:02 |
cp16net | well i think the upgrades should be defined in a different way than relying on the datastore version table | 21:02 |
demorris | yes | 21:02 |
kevinconway | you can't upgrade between those though | 21:02 |
cp16net | right.. | 21:03 |
kevinconway | that would be a migration, yes? | 21:03 |
demorris | you can migrate between 5.1 and 5.5, its tricky and there are tons of pitfalls, but you can technically do it | 21:03 |
kevinconway | right, but it's much more involved than applying a security patch | 21:03 |
kevinconway | and there are backwards incompatibilities | 21:03 |
demorris | correct | 21:04 |
demorris | correct | 21:04 |
cp16net | yea | 21:04 |
kevinconway | so why wouldn't those be different types | 21:04 |
kevinconway | i can describe going from mysql to postgresql the same way | 21:04 |
hub_cap | exactly | 21:04 |
kevinconway | its involved and incompatibile | 21:04 |
cp16net | thats more like a integration than just a migration/upgrade | 21:05 |
demorris | RDS supports major version upgrades | 21:05 |
demorris | for MySQL | 21:05 |
*** jcooley_ has joined #openstack-trove | 21:05 | |
kevinconway | demorris: i've done migration services between most versions and vendors of relational databases, that's not a super hard problem to solve | 21:06 |
kevinconway | but we also support nosql | 21:06 |
hub_cap | demorris: and we might too one day | 21:06 |
hub_cap | but that doesnt mean it makes things easier to deal w/ a major/minor version | 21:07 |
demorris | hub_cap: kevinconway right, and I am not saying it something that has to work day 1, point is that it IS possible to automate it for certain cases | 21:07 |
demorris | that was all | 21:07 |
kevinconway | well let me ask this, whats the difference between update and migration? | 21:07 |
kevinconway | is update in place and migration not in place? | 21:07 |
cp16net | can i go from mysql 5.1 to mongo? | 21:08 |
kevinconway | and i mean within the same trove instance for in-place and requiring a new trove instance for not-in-place | 21:08 |
cp16net | that would be crazy | 21:08 |
demorris | I would say to the user it does not matter…mincing words with upgrade and migration | 21:08 |
cp16net | lol | 21:08 |
kevinconway | i think it's an important distiction | 21:08 |
kevinconway | if update is in place then versions must support in place updates between them | 21:08 |
kevinconway | otherwise it may as well be a new datastore type | 21:09 |
demorris | I would consider an upgrade to be within the context of a type (MySQL, Redis, etc.) | 21:09 |
demorris | whether its major or minor | 21:09 |
kevinconway | i think we're talking about two different cases here. you're talking about end user. | 21:09 |
kevinconway | you can lie to end users and call everything an update | 21:10 |
cp16net | lol | 21:10 |
kevinconway | but from a trove perspective i don't think you can update 5.1 to 5.5. that's a migration. | 21:10 |
demorris | kevinconway: http://dev.mysql.com/doc/refman/5.5/en/upgrading-from-previous-series.html | 21:11 |
demorris | it's an upgrade | 21:11 |
demorris | :) | 21:11 |
kevinconway | lol | 21:11 |
cp16net | thats alot of word | 21:11 |
cp16net | +s | 21:12 |
cp16net | you basically have to maek sure users undertand those issues | 21:12 |
cp16net | but that should NOT be inplace | 21:12 |
cp16net | incase it screws everything up and a user needs to go back to the original system | 21:13 |
cp16net | i think its should be similar-esk to the restore | 21:13 |
cp16net | on a new instance and the user can decide if they want to go on with it or not | 21:13 |
kevinconway | cp16net: yeah, it's pretty easy to stream data from one relational database to another | 21:14 |
cp16net | sure | 21:14 |
demorris | there are a lot of ways to do it | 21:14 |
demorris | user can create a backup | 21:14 |
demorris | try the upgrade (in place) | 21:14 |
demorris | if it fails..restore to backup | 21:15 |
kevinconway | demorris: then what? | 21:15 |
kevinconway | they just can't upgade? | 21:15 |
demorris | call support? :) | 21:15 |
kevinconway | lol, why not just call them at the beginning and have a dba do the whole thing? | 21:15 |
demorris | joking aside, I am simply saying that just because something could go wrong is not a reason that it would never work | 21:16 |
*** OpenStack1 has quit IRC | 21:16 | |
demorris | the question at the root of this is if you should allow for major version upgrades | 21:16 |
demorris | I think the system should and the provider decides if they want to support that | 21:16 |
demorris | the API should not restrict it outright | 21:17 |
demorris | looking more at the code I feel like it already does this | 21:17 |
kevinconway | i think i get what you're saying | 21:18 |
kevinconway | target compatibility to a datastore type and assume everything a provider puts as a version of that type is compatible with configs and can easily update in-place | 21:18 |
demorris | more or less, but amcrn has an interesting approach on this documented here - https://gist.github.com/amcrn/dfd493200fcdfdb61a23 | 21:20 |
demorris | I think that allows a provider to decide what paths to enable and a specific manager written to take care of them | 21:20 |
kevinconway | yeah he's all about that compat matrix | 21:22 |
kevinconway | i think it's unnecessary | 21:22 |
kevinconway | if we define version updates to be in-place package changes then we just add a new guest agent method to handle it | 21:22 |
kevinconway | and type migrations get handled by something else | 21:23 |
demorris | I see | 21:24 |
demorris | well in that case, if the guest agent just handles minor version updates | 21:25 |
demorris | nm, incomplete thought | 21:25 |
kevinconway | well and minor version updates may still be MySuperDB6 to MySuperDB7 | 21:26 |
kevinconway | depending on the version numbers used | 21:26 |
* amcrn is back | 21:26 | |
kevinconway | its whatever can be done in place | 21:26 |
*** OpenStack1 has joined #openstack-trove | 21:29 | |
demorris | right | 21:30 |
demorris | so lets go back to the original problem | 21:30 |
demorris | I have a bunch of configurations and I want to associate them with a type (MySQL, Redis, MongoDB, Cassandra, etc.) and a major versions (X . X) | 21:31 |
kevinconway | so the question was do we target config compat at types or individual version right? | 21:31 |
demorris | I do not want to associate them with minor versions, or I would say, we can leave that out of scope | 21:32 |
kevinconway | again, you're distinguishing between major and minor versions | 21:32 |
demorris | yes | 21:32 |
kevinconway | what's the distinction? | 21:32 |
kevinconway | trove doesn't know what a major versus minor version is | 21:33 |
kevinconway | it just knows type and version | 21:33 |
amcrn | agreed | 21:33 |
demorris | okay well what if I say it should | 21:33 |
kevinconway | then what is the distinction between major and minor version? | 21:33 |
kevinconway | because it can't be the numbers. those are meaningless | 21:34 |
demorris | okay so let me back up | 21:35 |
hub_cap | demorris: do u take two steps forward while kevinconway takes two steps back? | 21:35 |
hub_cap | you come together cuz opposites attract? | 21:35 |
hub_cap | from what i hear, "it aint fiction, its a natural fact"... so we dont mind | 21:36 |
demorris | oh so you are breaking out the Paula Abdul | 21:36 |
amcrn | lol | 21:36 |
demorris | I see how it is | 21:36 |
hub_cap | demorris: :) | 21:36 |
*** jmontemayor has quit IRC | 21:37 | |
amcrn | demorris: example: mongodb introduced noautosplit in 2.0.7. even if you modeled your datastores after major.minor, there's no way of validating that noautosplit shouldn't be in a 2.0.6 configuration-group. | 21:38 |
demorris | amcrn: gotcha, and I was just thinking of the following example…5.1 - 5.5 MySQL | 21:38 |
demorris | innodb_buffer_pool_shm_key and innodb_buffer_pool_shm_checksum were removed from 5.1 to 5.5 | 21:39 |
amcrn | your assumption is that library maintainers follow the rules, but that's a dangerous presumption ;) | 21:39 |
demorris | but I believe in Percona distributions they kept them around for compatibly reasons and issue a warning…not sure how MySQL handles if they are present | 21:39 |
demorris | hehe yeah | 21:39 |
demorris | perhaps I am over thinking | 21:39 |
*** jcooley_ has quit IRC | 21:41 | |
*** yogesh has joined #openstack-trove | 21:43 | |
amcrn | another example: require_client_auth for client_encryption_options was introduced in cassandra 1.2.3 | 21:44 |
amcrn | it could be said that these are few and far between, but they do exist | 21:44 |
amcrn | which leads me to believe that configuration-group parameter validation should be on a datastore-version level, not datastore-type | 21:45 |
amcrn | there are many ways that can be accomplished, but i think getting a consensus on this fact is what will drive it forward | 21:46 |
*** OpenStack1 has quit IRC | 21:47 | |
*** harlowja has quit IRC | 21:50 | |
* amcrn starts chatting with the crickets, asking how their day was | 21:51 | |
cp16net | lolz | 21:51 |
demorris | amcrn: thinking | 21:51 |
cp16net | chirp chirp | 21:51 |
amcrn | ;) | 21:51 |
*** jcooley_ has joined #openstack-trove | 21:52 | |
*** SergeyLukjanov_ has quit IRC | 21:53 | |
*** mmcdaris has joined #openstack-trove | 21:56 | |
*** jcooley_ has quit IRC | 21:57 | |
*** harlowja has joined #openstack-trove | 22:00 | |
*** jcooley_ has joined #openstack-trove | 22:01 | |
*** greghill has quit IRC | 22:03 | |
demorris | amcrn: good example, but even with that, why not still extend it to be associated with both the type and the version id | 22:03 |
amcrn | the version-id is fk'd to the type, so it's effectively the same thing | 22:04 |
amcrn | the version-id is effectively the type+version | 22:04 |
demorris | i see... | 22:05 |
amcrn | now, whether that's exposed to the provider as version-id, or as type+version-name, that's a choice that can be made | 22:06 |
demorris | swhat about allowing tying it to multiple version id's | 22:07 |
amcrn | tying a validation-rules set to multiple version-ids? sure | 22:07 |
*** pdmars has quit IRC | 22:08 | |
amcrn | right now, the abstraction for the sinew is the "manager". the manager is tied to a validation-rule set, which implicitly means that we need to tie a version-id to a manager to achieve the goal | 22:09 |
amcrn | and many version-ids can tie to a single manager | 22:09 |
amcrn | but is the manager the right connector? | 22:09 |
demorris | not sure, I am not at all familiar with the code, so I am getting a tad lost | 22:11 |
demorris | :) | 22:11 |
cp16net | a tad is an understatment | 22:12 |
cp16net | :-P | 22:12 |
demorris | thanks cp16net | 22:12 |
hub_cap | should we have this convo 1) on the ml | 22:12 |
hub_cap | or 2) on monday? | 22:12 |
hub_cap | :) | 22:12 |
amcrn | cp16net: have i lost you as well? | 22:13 |
hub_cap | since its like almost knocking off time for the austinites and the mirantis guys are gone | 22:13 |
cp16net | i dont know as much as lost me as i just lost myself | 22:13 |
amcrn | hrm, sorry :/ | 22:13 |
cp16net | :-P | 22:13 |
amcrn | are we in agreement that validation should be on a version basis vs. a datastore basis? if so, we have progress, we just need to determine *how* | 22:14 |
datsun180b | 4:15 better not be "almost knocking off time" for us | 22:14 |
kevinconway | speaking of ML, have you folks been following the universal guest agent thread? | 22:15 |
cp16net | 5 min :-P | 22:15 |
kevinconway | they seem to know a lot about what we want and need | 22:15 |
kevinconway | and by that i mean they say "This would be great for Trove" a lot | 22:15 |
datsun180b | http://www.youtube.com/watch?v=mSy5mEcmgwU kevinconway | 22:15 |
* amcrn away | 22:16 | |
*** harlowja has quit IRC | 22:16 | |
*** harlowja has joined #openstack-trove | 22:24 | |
*** jcooley_ has quit IRC | 22:25 | |
*** harlowja has quit IRC | 22:27 | |
*** kevinconway has quit IRC | 22:27 | |
*** harlowja has joined #openstack-trove | 22:28 | |
*** amytron has quit IRC | 22:29 | |
*** robertmyers has quit IRC | 22:31 | |
*** denis_makogon_ has joined #openstack-trove | 22:35 | |
*** demorris has quit IRC | 22:40 | |
*** Barker has quit IRC | 22:51 | |
*** Barker has joined #openstack-trove | 22:52 | |
*** Barker has quit IRC | 22:56 | |
*** mmcdaris has left #openstack-trove | 23:04 | |
*** Barker has joined #openstack-trove | 23:07 | |
*** OpenStack1 has joined #openstack-trove | 23:08 | |
*** datsun180b has quit IRC | 23:10 | |
*** Barker has quit IRC | 23:14 | |
openstackgerrit | A change was merged to openstack/python-troveclient: Updates README with new trove help options https://review.openstack.org/58834 | 23:17 |
*** yogesh has quit IRC | 23:20 | |
*** rnirmal has quit IRC | 23:20 | |
*** SushilGL has quit IRC | 23:24 | |
*** jasonb365 has quit IRC | 23:27 | |
*** greghill has joined #openstack-trove | 23:31 | |
*** OpenStack1 has quit IRC | 23:50 | |
*** flaper87 is now known as flaper87|afk | 23:50 | |
*** denis_makogon_ has quit IRC | 23:51 | |
*** grapex has quit IRC | 23:52 | |
*** jcru has quit IRC | 23:53 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!