| openstackgerrit | Michael Yu proposed a change to openstack/trove: Adds Backup/Restore support for Couchbase https://review.openstack.org/86731 | 00:10 |
|---|---|---|
| openstackgerrit | Michael Yu proposed a change to openstack/trove: Adds Backup/Restore support for Couchbase https://review.openstack.org/86731 | 00:13 |
| openstackgerrit | Michael Yu proposed a change to openstack/trove: Adds Backup/Restore support for Couchbase https://review.openstack.org/86731 | 00:13 |
| *** demorris has quit IRC | 00:13 | |
| *** achampion has joined #openstack-trove | 00:45 | |
| *** annashen_ has joined #openstack-trove | 00:52 | |
| *** yidclare has joined #openstack-trove | 00:55 | |
| *** yidclare has quit IRC | 01:07 | |
| *** annashen_ has quit IRC | 01:28 | |
| *** nosnos has joined #openstack-trove | 01:49 | |
| *** nosnos has quit IRC | 01:55 | |
| *** nosnos has joined #openstack-trove | 01:55 | |
| *** robertmyers has joined #openstack-trove | 01:56 | |
| *** boden has quit IRC | 02:03 | |
| *** annashen_ has joined #openstack-trove | 02:11 | |
| *** mattgriffin has joined #openstack-trove | 02:18 | |
| *** ajc_ has joined #openstack-trove | 02:50 | |
| *** nehav has joined #openstack-trove | 03:07 | |
| *** ramishra has joined #openstack-trove | 03:11 | |
| *** robertmyers has quit IRC | 03:17 | |
| *** nosnos has quit IRC | 03:27 | |
| openstackgerrit | Nikhil Manchanda proposed a change to openstack/trove: Cleaned up sample trove-guestagent.conf https://review.openstack.org/104062 | 03:40 |
| openstackgerrit | Nikhil Manchanda proposed a change to openstack/trove: Cleaned up sample trove-guestagent.conf https://review.openstack.org/104062 | 03:43 |
| *** mattgriffin has quit IRC | 03:49 | |
| *** nehav has quit IRC | 03:50 | |
| *** coolsvap|afk is now known as coolsvap | 03:53 | |
| *** ramishra has quit IRC | 04:37 | |
| *** nosnos has joined #openstack-trove | 04:42 | |
| *** ramishra has joined #openstack-trove | 04:49 | |
| *** SushillKM has joined #openstack-trove | 05:23 | |
| *** rwsu has quit IRC | 05:24 | |
| *** juantwo has quit IRC | 05:24 | |
| *** eghobo has joined #openstack-trove | 05:30 | |
| *** sgotliv has joined #openstack-trove | 05:35 | |
| *** nehav has joined #openstack-trove | 05:52 | |
| *** eguz has joined #openstack-trove | 05:53 | |
| *** eghobo has quit IRC | 05:57 | |
| *** nehav has quit IRC | 06:01 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/trove: Imported Translations from Transifex https://review.openstack.org/104074 | 06:05 |
| openstackgerrit | Nikhil Manchanda proposed a change to openstack/trove: Cleaned up sample trove-guestagent.conf https://review.openstack.org/104062 | 06:40 |
| *** julienvey has joined #openstack-trove | 06:50 | |
| *** eguz has quit IRC | 06:55 | |
| *** karimb has joined #openstack-trove | 07:03 | |
| *** karimb has quit IRC | 07:05 | |
| *** karimb has joined #openstack-trove | 07:06 | |
| *** julienvey has quit IRC | 07:07 | |
| *** flaper87|afk is now known as flaper87 | 07:19 | |
| *** annashen_ has quit IRC | 07:24 | |
| *** flaper87 is now known as flaper87|afk | 07:35 | |
| *** sgotliv has quit IRC | 07:46 | |
| openstackgerrit | Craig Vyvial proposed a change to openstack/trove: parse the mysql cnf file for password https://review.openstack.org/104107 | 08:10 |
| openstackgerrit | Craig Vyvial proposed a change to openstack/trove: guestagent contract for packages should be a list https://review.openstack.org/104108 | 08:10 |
| *** fifieldt_ has joined #openstack-trove | 08:16 | |
| *** flaper87|afk is now known as flaper87 | 08:17 | |
| *** julienvey has joined #openstack-trove | 08:18 | |
| *** fifieldt has quit IRC | 08:18 | |
| *** ViswaV_ has joined #openstack-trove | 08:20 | |
| *** julienvey has quit IRC | 08:22 | |
| *** ViswaV has quit IRC | 08:24 | |
| *** ramishra has quit IRC | 08:30 | |
| *** ramishra has joined #openstack-trove | 08:30 | |
| *** fifieldt_ is now known as fifieldt | 08:31 | |
| *** boden has joined #openstack-trove | 08:37 | |
| *** sgotliv has joined #openstack-trove | 09:02 | |
| *** Longgeek has joined #openstack-trove | 09:03 | |
| *** Longgeek has quit IRC | 09:03 | |
| *** Longgeek has joined #openstack-trove | 09:04 | |
| *** sgotliv has quit IRC | 09:08 | |
| *** sgotliv has joined #openstack-trove | 09:09 | |
| *** ramishra has quit IRC | 09:27 | |
| *** ramishra has joined #openstack-trove | 09:35 | |
| *** Longgeek has quit IRC | 10:03 | |
| *** Longgeek has joined #openstack-trove | 10:03 | |
| *** Longgeek has quit IRC | 10:07 | |
| *** ramishra has quit IRC | 10:21 | |
| *** Longgeek has joined #openstack-trove | 10:21 | |
| *** ramishra_ has joined #openstack-trove | 10:25 | |
| *** sgotliv has quit IRC | 10:37 | |
| *** ramishra_ has quit IRC | 10:39 | |
| *** sgotliv has joined #openstack-trove | 11:05 | |
| *** Longgeek has quit IRC | 11:10 | |
| *** Longgeek has joined #openstack-trove | 11:10 | |
| *** sgotliv has quit IRC | 11:12 | |
| *** SushillKM has quit IRC | 11:17 | |
| *** coolsvap is now known as coolsvap|afk | 11:23 | |
| *** sgotliv has joined #openstack-trove | 11:26 | |
| *** sgotliv has quit IRC | 11:39 | |
| *** sgotliv has joined #openstack-trove | 11:39 | |
| *** ajc_ has quit IRC | 11:58 | |
| *** nosnos has quit IRC | 11:59 | |
| *** nosnos has joined #openstack-trove | 11:59 | |
| *** sgotliv has quit IRC | 12:01 | |
| *** SushillKM has joined #openstack-trove | 12:01 | |
| *** Longgeek_ has joined #openstack-trove | 12:02 | |
| *** juantwo has joined #openstack-trove | 12:03 | |
| *** nosnos has quit IRC | 12:04 | |
| *** Longgeek has quit IRC | 12:06 | |
| *** Longgeek_ has quit IRC | 12:07 | |
| *** Longgeek has joined #openstack-trove | 12:08 | |
| *** sgotliv has joined #openstack-trove | 12:14 | |
| *** pdmars has joined #openstack-trove | 12:27 | |
| *** achampion has quit IRC | 12:27 | |
| *** pdmars_ has joined #openstack-trove | 12:31 | |
| *** pdmars has quit IRC | 12:31 | |
| *** nehav has joined #openstack-trove | 12:37 | |
| openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/trove: Updated from global requirements https://review.openstack.org/104023 | 12:39 |
| *** SushillKM has quit IRC | 12:44 | |
| *** demorris has joined #openstack-trove | 12:54 | |
| *** radez_g0n3 is now known as radez | 12:55 | |
| openstackgerrit | iccha-sethi proposed a change to openstack/trove: Allow users the ability to update the instance name https://review.openstack.org/92701 | 13:13 |
| *** sgotliv has quit IRC | 13:34 | |
| *** nehav has quit IRC | 13:37 | |
| *** ViswaV_ has quit IRC | 13:41 | |
| *** ViswaV has joined #openstack-trove | 13:43 | |
| *** sgotliv has joined #openstack-trove | 13:48 | |
| *** thedodd has joined #openstack-trove | 13:51 | |
| *** jcru has joined #openstack-trove | 13:52 | |
| *** jcru has quit IRC | 13:52 | |
| *** jcru has joined #openstack-trove | 13:53 | |
| *** miqui has quit IRC | 13:56 | |
| *** robertmyers has joined #openstack-trove | 13:57 | |
| *** juantwo has quit IRC | 14:01 | |
| *** mattgriffin has joined #openstack-trove | 14:07 | |
| *** achampion has joined #openstack-trove | 14:09 | |
| *** rwsu has joined #openstack-trove | 14:10 | |
| *** juantwo has joined #openstack-trove | 14:12 | |
| *** grapex has joined #openstack-trove | 14:13 | |
| *** grapex__ has joined #openstack-trove | 14:14 | |
| *** grapex has quit IRC | 14:17 | |
| *** glucas has left #openstack-trove | 14:19 | |
| *** jmontemayor has joined #openstack-trove | 14:22 | |
| *** jmontemayor_ has joined #openstack-trove | 14:23 | |
| *** demorris has quit IRC | 14:25 | |
| *** jmontemayor has quit IRC | 14:27 | |
| *** glucas has joined #openstack-trove | 14:28 | |
| *** juantwo has quit IRC | 14:29 | |
| *** jcru_ has joined #openstack-trove | 14:29 | |
| *** jcru has quit IRC | 14:30 | |
| *** demorris has joined #openstack-trove | 14:31 | |
| *** jcru has joined #openstack-trove | 14:39 | |
| *** amytron has joined #openstack-trove | 14:41 | |
| *** jcru_ has quit IRC | 14:41 | |
| *** juantwo has joined #openstack-trove | 14:43 | |
| *** juantwo has quit IRC | 14:44 | |
| *** juantwo has joined #openstack-trove | 14:44 | |
| *** jcru has quit IRC | 14:47 | |
| *** Gordon has joined #openstack-trove | 14:48 | |
| *** Gordon is now known as Guest86005 | 14:48 | |
| *** Guest86005 has quit IRC | 14:48 | |
| *** coolsvap|afk is now known as coolsvap | 14:53 | |
| *** annashen_ has joined #openstack-trove | 14:58 | |
| *** demorris has quit IRC | 14:59 | |
| *** miqui has joined #openstack-trove | 14:59 | |
| *** robertmy_ has joined #openstack-trove | 14:59 | |
| *** robertmyers has quit IRC | 15:02 | |
| *** robertmy_ has quit IRC | 15:03 | |
| *** robertmyers has joined #openstack-trove | 15:03 | |
| *** nehav has joined #openstack-trove | 15:07 | |
| *** demorris has joined #openstack-trove | 15:08 | |
| *** mattgriffin has quit IRC | 15:11 | |
| *** jcru has joined #openstack-trove | 15:16 | |
| *** jcru has quit IRC | 15:16 | |
| *** jcru has joined #openstack-trove | 15:17 | |
| openstackgerrit | Rueben Ramirez proposed a change to openstack/trove: Extends datastore capability overrides and adds management cmds https://review.openstack.org/104011 | 15:29 |
| *** demorris has quit IRC | 15:42 | |
| *** juantwo has quit IRC | 15:51 | |
| openstackgerrit | amrith proposed a change to openstack/trove: Logging audit for trove/db module https://review.openstack.org/103953 | 15:51 |
| *** nehav has quit IRC | 15:52 | |
| *** pdmars_ has quit IRC | 15:54 | |
| *** jmontemayor_ has quit IRC | 15:54 | |
| *** demorris has joined #openstack-trove | 15:59 | |
| *** jmontemayor has joined #openstack-trove | 16:01 | |
| *** nehav has joined #openstack-trove | 16:01 | |
| *** demorris_ has joined #openstack-trove | 16:02 | |
| *** jmontemayor_ has joined #openstack-trove | 16:03 | |
| *** jmontemayor has quit IRC | 16:03 | |
| *** eghobo has joined #openstack-trove | 16:03 | |
| *** demorris has quit IRC | 16:04 | |
| *** demorris_ is now known as demorris | 16:04 | |
| *** iccha1 has quit IRC | 16:05 | |
| *** nehav has quit IRC | 16:06 | |
| *** nehav1 has joined #openstack-trove | 16:06 | |
| *** eghobo has quit IRC | 16:08 | |
| *** eghobo has joined #openstack-trove | 16:08 | |
| *** juantwo has joined #openstack-trove | 16:10 | |
| *** Gordon has joined #openstack-trove | 16:11 | |
| *** Gordon is now known as Guest80475 | 16:12 | |
| *** coolsvap is now known as coolsvap|afk | 16:12 | |
| *** annashen_ has quit IRC | 16:12 | |
| *** Guest80475 has quit IRC | 16:12 | |
| *** mattgriffin has joined #openstack-trove | 16:18 | |
| *** ViswaV_ has joined #openstack-trove | 16:26 | |
| *** yidclare has joined #openstack-trove | 16:28 | |
| *** ViswaV has quit IRC | 16:29 | |
| *** flaper87 is now known as flaper87|afk | 16:34 | |
| *** ViswaV has joined #openstack-trove | 16:35 | |
| *** ViswaV__ has joined #openstack-trove | 16:35 | |
| *** ViswaV_ has quit IRC | 16:38 | |
| *** dkehn__ has joined #openstack-trove | 16:39 | |
| *** ViswaV has quit IRC | 16:39 | |
| *** karimb has quit IRC | 16:41 | |
| *** dkehnx has quit IRC | 16:41 | |
| *** Isotopp has quit IRC | 16:43 | |
| *** thedodd has quit IRC | 16:44 | |
| *** sgotliv has quit IRC | 16:50 | |
| *** Isotopp has joined #openstack-trove | 16:55 | |
| *** demorris has quit IRC | 16:55 | |
| *** dkehn__ is now known as dkehnx | 16:57 | |
| *** iccha has joined #openstack-trove | 16:59 | |
| *** nehav1 has quit IRC | 16:59 | |
| *** juantwo has quit IRC | 16:59 | |
| *** Longgeek has quit IRC | 17:02 | |
| *** jmontemayor_ has quit IRC | 17:03 | |
| *** nehav has joined #openstack-trove | 17:04 | |
| *** demorris has joined #openstack-trove | 17:05 | |
| *** yidclare has quit IRC | 17:07 | |
| *** yidclare has joined #openstack-trove | 17:08 | |
| *** annashen_ has joined #openstack-trove | 17:09 | |
| *** juantwo has joined #openstack-trove | 17:11 | |
| *** juantwo has quit IRC | 17:13 | |
| *** juantwo has joined #openstack-trove | 17:13 | |
| *** eghobo has quit IRC | 17:14 | |
| *** SnowDust has joined #openstack-trove | 17:20 | |
| *** dkehn__ has joined #openstack-trove | 17:21 | |
| *** amcrn has joined #openstack-trove | 17:23 | |
| *** dkehn__ has quit IRC | 17:23 | |
| *** dkehn__ has joined #openstack-trove | 17:24 | |
| *** dkehnx has quit IRC | 17:25 | |
| *** dkehn__ is now known as dkehnx | 17:26 | |
| *** iccha has quit IRC | 17:27 | |
| *** michael-yu has joined #openstack-trove | 17:31 | |
| *** michael-yu has quit IRC | 17:31 | |
| *** michael-yu has joined #openstack-trove | 17:32 | |
| *** demorris has quit IRC | 17:42 | |
| *** nehav has quit IRC | 17:44 | |
| *** saurabhs has joined #openstack-trove | 17:46 | |
| *** grapex__ has quit IRC | 17:47 | |
| *** kevinconway has joined #openstack-trove | 17:47 | |
| *** grapex has joined #openstack-trove | 17:47 | |
| *** iccha has joined #openstack-trove | 17:47 | |
| *** openstackgerrit has quit IRC | 17:49 | |
| *** openstackgerrit has joined #openstack-trove | 17:49 | |
| *** denis_makogon_ has joined #openstack-trove | 17:50 | |
| *** iccha has quit IRC | 17:50 | |
| *** iccha has joined #openstack-trove | 17:50 | |
| *** denis_makogon has quit IRC | 17:51 | |
| *** denis_makogon_ is now known as denis_makogon | 17:51 | |
| *** dmakogon_ has joined #openstack-trove | 17:51 | |
| *** Yogesh has joined #openstack-trove | 18:07 | |
| *** shayneburgess has joined #openstack-trove | 18:07 | |
| *** saurabhs1 has joined #openstack-trove | 18:11 | |
| *** saurabhs has quit IRC | 18:14 | |
| *** shayneburgess has left #openstack-trove | 18:24 | |
| *** shayneburgess has joined #openstack-trove | 18:25 | |
| *** michael-yu has quit IRC | 18:25 | |
| *** michael-yu has joined #openstack-trove | 18:26 | |
| *** jmontemayor has joined #openstack-trove | 18:27 | |
| *** nehav has joined #openstack-trove | 18:36 | |
| *** nehav has quit IRC | 18:37 | |
| *** michael-yu has quit IRC | 18:38 | |
| *** saurabhs1 has quit IRC | 18:43 | |
| *** saurabhs has joined #openstack-trove | 18:43 | |
| *** eghobo has joined #openstack-trove | 18:47 | |
| *** eghobo has quit IRC | 18:47 | |
| *** eghobo has joined #openstack-trove | 18:48 | |
| *** michael-yu has joined #openstack-trove | 18:49 | |
| *** demorris has joined #openstack-trove | 18:57 | |
| *** tvoran has joined #openstack-trove | 18:59 | |
| *** yidclare has quit IRC | 19:01 | |
| amrith | SlickNik, are we going to contine the conversation here? | 19:01 |
| SnowDust | hi denis_makogon: lets talk then | 19:01 |
| *** mat-lowery_ is now known as mat-lowery | 19:01 | |
| SlickNik | yes. | 19:01 |
| *** tvoran_ has joined #openstack-trove | 19:02 | |
| SlickNik | amrith, grapex, iccha, vipul, dougshelley66: got a couple of minutes | 19:02 |
| vipul | sure.. | 19:02 |
| grapex | SlickNik: Unfortunately no, we've got two hours of meetings here. :( | 19:02 |
| SnowDust | hello team .. lets talk vertica datastore patchsets .. | 19:03 |
| *** rueben has joined #openstack-trove | 19:03 | |
| SnowDust | denis_makogon u there ? | 19:03 |
| denis_makogon | yes | 19:03 |
| amrith | is there a blueprint for the capability that iccha is looking to implement? she shared amrith: we want to offer two db's one with volumes and one without in the same trove instance | 19:03 |
| SnowDust | so breifing u .. last wed meeting .. majority of team ..was interested in the same patchset without a split | 19:03 |
| amrith | she shared: https://blueprints.launchpad.net/trove/+spec/per-datastore-volume-support | 19:03 |
| amrith | robertmeyers said: amrith: we want to offer two db's one with volumes and one without in the same trove instance | 19:04 |
| *** jmontemayor has quit IRC | 19:04 | |
| *** iccha_ has joined #openstack-trove | 19:04 | |
| rueben | wanted to ask about tempest test failures.... | 19:04 |
| amrith | am I understanding this correct? | 19:04 |
| *** tvoran_ has quit IRC | 19:04 | |
| iccha_ | got dc | 19:04 |
| rueben | http://logs.openstack.org/11/104011/2/check/check-tempest-dsvm-full/b186146/console.html#_2014-07-02... | 19:04 |
| *** tvoran__ has joined #openstack-trove | 19:04 | |
| rueben | ...the only thing that's failing on my patch set 2 https://review.openstack.org/#/c/104011/ | 19:04 |
| *** jmontemayor has joined #openstack-trove | 19:04 | |
| vipul | amrith: sounds about right | 19:05 |
| *** tvoran has quit IRC | 19:05 | |
| *** iccha has quit IRC | 19:05 | |
| iccha_ | amrith: i got dc, back online | 19:06 |
| SnowDust | ?? denis_makogon .. | 19:06 |
| *** tvoran__ has quit IRC | 19:06 | |
| glucas | amrith: Seems to be the use case used in the capabilities spec as well | 19:06 |
| *** tvoran has joined #openstack-trove | 19:06 | |
| glucas | i.e. Trove has a a capability for volume support, but operators can choose what datastore versions use that capability | 19:07 |
| denis_makogon | SnowDust, SlickNik Yogesh, my concern about single patchset is that main patchset for vertica datastore proposes too much changes that are not related to vertica at atll | 19:07 |
| denis_makogon | *at all | 19:07 |
| *** jmontemayor_ has joined #openstack-trove | 19:07 | |
| denis_makogon | the things like CRUD extensions | 19:07 |
| SnowDust | denis_makogon : the entirety of the patchset is just for vertica implementation .. and thats the BP | 19:08 |
| denis_makogon | it hasn't been discussed at all | 19:08 |
| SlickNik | grapex / iccha_: What's a good time that works for you guys to close the loop on this? | 19:08 |
| SlickNik | this being how the volumes per datastore ties in with the capabilities bp in progress. | 19:09 |
| iccha_ | SlickNik: does in two hours work for you? | 19:09 |
| denis_makogon | SnowDust, no, completely, BP says, we would implement users/schemes/root API, but it's impossible in terms of current framework | 19:09 |
| iccha_ | but from the meeting i got the consensus was we start off with config values for groups like [mysql] and tie that into what we decide the general strategy for capabilties is SlickNik | 19:10 |
| denis_makogon | SlickNik, SnowDust, vertica features should be iterated | 19:10 |
| amrith | sorry, am back. just stepped away for a second. | 19:10 |
| denis_makogon | 1. main things (provisioning, resizing, etc). | 19:10 |
| denis_makogon | 2. backup/restore | 19:10 |
| SnowDust | denis_makogon, but do u think the framework got changed ? is it such a change ? | 19:11 |
| *** jmontemayor has quit IRC | 19:11 | |
| *** rueben has quit IRC | 19:11 | |
| iccha_ | SlickNik: there might be additional concerns to be addressed. our responses depend on trove_support_volume and this is a general concern irrespective of which strategy we use. its highlighted in the wiki page | 19:11 |
| denis_makogon | 3. extensions refactoring (probably right after migration to pecan ReST framework) | 19:11 |
| denis_makogon | 4. CRUD | 19:11 |
| denis_makogon | SnowDust, of course it got changed, whole extension framework got refactored without any info in the BP | 19:12 |
| Yogesh | denis_makogon: I thought the changes were not drastic and on the lines of existing datastores | 19:12 |
| denis_makogon | SnowDust, those changes weren't approved | 19:12 |
| SnowDust | denis_makogon: the code remains around the same things using same core libraries from openstack.common | 19:13 |
| SnowDust | where is the framework change ? | 19:13 |
| denis_makogon | Yogesh, everything can fit to other datastores, but it hasn't been discussed at all | 19:13 |
| amrith | iccha_, SlickNik ... re: capabilities and iccha_'s bp, I didn't get the same understanding that she just mentioned. My understanding was that her BP is put on hold till we figure out what becomes of capabilities. | 19:13 |
| denis_makogon | SnowDust, committer changed trove/extension/ framework | 19:13 |
| denis_makogon | SnowDust, so, i would say - bring it to ML and let's discuss it there | 19:14 |
| Yogesh | denis_makogon: if there is a need, we can bring it on the table for discussion and review... | 19:14 |
| SnowDust | denis_makogon, sure | 19:14 |
| Yogesh | i agree that anything out of the datastore implementation should be discussed | 19:15 |
| denis_makogon | Yogesh, so why does commiter did un-approved changes? | 19:15 |
| Yogesh | denis_makogin: the reviewer can review and give comments | 19:16 |
| denis_makogon | i really think that whole patch should be iterated, in 3-4 stages | 19:16 |
| Yogesh | and they can be discussed in the forum | 19:16 |
| Yogesh | denis_makogon: its been ages that the patch has been there | 19:16 |
| Yogesh | a comment could've really paced things up | 19:17 |
| SnowDust | denis_makogon, its very fine line .. the framework change u are citing doesnot mean a lot until there is any services/components working changing they work similar | 19:17 |
| denis_makogon | Yogesh, i reviewed it not even once | 19:17 |
| denis_makogon | with same complains, and they were ignored | 19:17 |
| SnowDust | denis_makogon, :) who ignored .. we are still discussing / hearing u .. | 19:18 |
| denis_makogon | cool | 19:18 |
| Yogesh | SnowDust: i liked the idea of breaking... | 19:18 |
| glucas | SlickNik: question about oslo.db sync, since it just came up in the meeting... | 19:18 |
| SnowDust | but waiting for the community too | 19:18 |
| denis_makogon | then let this discussion will go to the ML | 19:18 |
| denis_makogon | glucas, yup =) | 19:18 |
| Yogesh | we can break the patchset into logical pieces | 19:18 |
| SnowDust | Yogesh, last mid week meeting.. SlickNik, amrith both suggested not to break | 19:19 |
| glucas | SlickNik: I've got https://review.openstack.org/#/c/91629 for which you said it should be part of an oslo db sync. Should this not be going in for now? | 19:19 |
| Yogesh | SlickNik: guidance? | 19:19 |
| denis_makogon | glucas, seems like yes | 19:19 |
| denis_makogon | glucas, oslo.db relays on [database] configuration group | 19:20 |
| Yogesh | vipul: SlickNik: Amrith: looking forward for inputs from you guys... | 19:20 |
| SlickNik | amrith: I don't think her volume per datastore bp necessarily needs to be put on hold. I think that (as vipul mentioned earlier), we could implement both her bp, and capabilities such that neither is blocked on the other. | 19:20 |
| glucas | denis_makogon: right, I'd proposed changes to support that but wasn't aware of the whole oslo sync process at the time.. | 19:21 |
| amrith | SlickNik, I don't know how you would do that without having rework later. | 19:21 |
| denis_makogon | glucas, so am i, but now, we're on the same page and now we know what and when we'll do | 19:21 |
| amrith | in the long run, I think it would be easier if her BP used a simple impl of capabilities which abstracts that functionality. | 19:22 |
| SlickNik | amrith: What is the plan for capability values that exist in the config file today (i.e. volume_support)? | 19:22 |
| amrith | that's the question, right. What I'm proposing is that the implementation of capabilities shoudl make that transparent to the consumer (in this case, iccha's code) | 19:23 |
| amrith | what is being proposed is that she go off and impelement some code to go and directly read out of config files. | 19:23 |
| amrith | this breaks a future abstraction; or at least means that this abstraction will have to rework her code AND move the volume support wherever it wants. | 19:24 |
| SlickNik | Even without talking about iccha's code, from a pure design perspective, what's our story around capability values that exist in the config file today? | 19:24 |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Make storage strategy available for trove API and TM https://review.openstack.org/86242 | 19:25 |
| amrith | from a pure design perspective, I think there are some things which will remain in config files, albeit very limited or potentially going to zero over time. | 19:25 |
| amrith | i.e. the access to config files would be through capabilities | 19:25 |
| SlickNik | amrith: FWIW I think that's the proposal. Use a version of capabilities that doesn't rely on the API / db pieces that are still being fleshed out, but instead rely on the "fallback to config file" behavior that we're probably going to need in the long run anyway. | 19:25 |
| amrith | that was my understanding. | 19:25 |
| amrith | SlickNik, my last comment was a continuation of my previous statement, not a response to your comment. | 19:26 |
| amrith | That said, I believe that what iccha_ is saying is that the code they will go ahead and implement something that directly reads config files. I'm searching for what she exactly said to verify, ... | 19:27 |
| amrith | here ... | 19:28 |
| amrith | but from the meeting i got the consensus was we start off with config values for groups like [mysql] and tie that into what we decide the general strategy for capabilties is | 19:28 |
| amrith | there might be additional concerns to be addressed. our responses depend on trove_support_volume and this is a general concern irrespective of which strategy we use. its highlighted in the wiki page | 19:28 |
| amrith | at 15:10 | 19:28 |
| amrith | which I understand to be different from the proposal you just described, a proposal by the way which I agree with. | 19:29 |
| SlickNik | amrith: yup, that's why I want to have a meeting to make sure we're on the same page. | 19:29 |
| amrith | At issue, I believe, is who "falls back to the config file". it is my opinion that the capabilities be the one that falls back. It is my understanding that what iccha is proposing is that her code fall back to config. | 19:29 |
| amrith | understood (re: your most recent comment, same page etc.,) | 19:30 |
| amrith | thanks! | 19:30 |
| SlickNik | iccha_: unfortunately I have 2 back-to-back hourly meetings at 2 PDT, so that doesn't work for me :( | 19:31 |
| SlickNik | amrith: So I think another issue at the heart of the matter is whether this "fallback" mechanism for capabilities is already implemented, or still needs to be (and whether the original design needs to be updated). | 19:36 |
| amrith | SlickNik, yes. I agree. | 19:36 |
| *** demorris has quit IRC | 19:41 | |
| *** yidclare has joined #openstack-trove | 19:42 | |
| SlickNik | glucas: if an oslo db sync gets us cleaner config options for the db connection, I'm all for it. | 19:43 |
| SlickNik | glucas: unless it's a monumental task (and a cost-benefit analysis indicates otherwise). | 19:43 |
| * anteaya lines up for some of SlickNik's time | 19:45 | |
| SlickNik | anteaya: I've been meaning to catch up with you and sukhdev this morning, but haven't had a chance yet. | 19:46 |
| anteaya | I'm here | 19:46 |
| anteaya | I haven't talked to sukhdev lately | 19:46 |
| anteaya | what can I do to help? | 19:46 |
| SlickNik | So I followed the instruction on the doc, but ran into some issues. | 19:46 |
| *** SnowDust has quit IRC | 19:46 | |
| anteaya | can you paste them? | 19:46 |
| anteaya | I'll chase down sudhdev | 19:46 |
| SlickNik | I did, but paste was acting flaky earlier and only pasted half of it. | 19:47 |
| SlickNik | I have a gist, one sec. | 19:47 |
| anteaya | kk | 19:47 |
| SlickNik | https://gist.github.com/anonymous/7984f4180fdd271a8c4f | 19:47 |
| anteaya | thanks | 19:47 |
| anteaya | SlickNik: okay let me see if I can track down Sukhdev | 19:48 |
| anteaya | thanks | 19:48 |
| openstackgerrit | A change was merged to openstack/trove: Add sample admin_{user,tenant_name,password} https://review.openstack.org/99296 | 19:49 |
| SlickNik | Okay, let's take this to #openstack-infra, | 19:49 |
| *** tvoran has quit IRC | 19:50 | |
| *** tvoran has joined #openstack-trove | 19:53 | |
| *** tvoran has quit IRC | 19:54 | |
| *** tvoran has joined #openstack-trove | 19:55 | |
| *** jmontemayor_ has quit IRC | 19:56 | |
| SlickNik | Yogesh / snowdust: I don't think the size of the changes is the issue (though small patches do make it easier for quick reviews). | 19:56 |
| SlickNik | The bigger issue here is that there's no way of testing / validating that these actually work. | 19:56 |
| SlickNik | I believe the bigger issue is how we can get some CI around validating datastore scenarios. | 19:56 |
| SlickNik | Something like running a "simple" set of integration tests, like spinning up an instance and making sure it come ACTIVE successfully (something like the "simple" group) would help a lot here. | 19:57 |
| *** zzelle has joined #openstack-trove | 19:58 | |
| *** SnowDust has joined #openstack-trove | 19:58 | |
| *** demorris has joined #openstack-trove | 20:00 | |
| *** michael-yu has quit IRC | 20:03 | |
| iccha_ | SlickNik: how abt 3 pm PDT? | 20:03 |
| *** demorris_ has joined #openstack-trove | 20:03 | |
| *** nehav has joined #openstack-trove | 20:04 | |
| *** demorris has quit IRC | 20:05 | |
| *** demorris_ is now known as demorris | 20:05 | |
| *** jmontemayor has joined #openstack-trove | 20:05 | |
| SnowDust | hi SlickNik, on vertica datastore patch .. your observations ? | 20:06 |
| *** tvoran has quit IRC | 20:06 | |
| SnowDust | i just joined back .. may be i missed | 20:06 |
| *** zzelle has left #openstack-trove | 20:06 | |
| *** tvoran has joined #openstack-trove | 20:07 | |
| Yogesh | SnowDust: lemme send you what SlickNIk said | 20:07 |
| SnowDust | sure .. | 20:07 |
| Yogesh | more on the lines of the test strategy we discussed the last time | 20:07 |
| SnowDust | ok .. means patchset will remain the same | 20:09 |
| SnowDust | no splits | 20:09 |
| esmute | denis_makogon: Do you have any other concern beside the use of "global"? If not, could you remove the -1 so that it doesnt prevent other people from looking at it? We need this fix asap. https://review.openstack.org/#/c/102585/ | 20:10 |
| *** thedodd has joined #openstack-trove | 20:10 | |
| *** boden has quit IRC | 20:11 | |
| *** SnowDust has quit IRC | 20:11 | |
| *** radez is now known as radez_g0n3 | 20:13 | |
| *** michael-yu has joined #openstack-trove | 20:18 | |
| *** rueben has joined #openstack-trove | 20:19 | |
| iccha_ | amrith: how do u suggest i look at the config for per datastore given that it doesnt exist for per datastore right now | 20:24 |
| *** ViswaV has joined #openstack-trove | 20:25 | |
| amrith | iccha_, I was hoping we could have a conversation with SlickNik and others on core and folks in rax to figure out what the best path is forward. | 20:25 |
| rueben | amrith: hey sorry! We're having a huge planning day today, which has made it hard to multi-task at rax | 20:26 |
| *** ViswaV__ has quit IRC | 20:26 | |
| amrith | rueben, sounds good. what about tomorrow? SlickNik had many meetings back to back (I thought). let me check | 20:27 |
| rueben | amrith: I'm not sure what everyone's availability is for the rest of the day | 20:27 |
| rueben | I believe tomorrow should be easier to meet | 20:27 |
| amrith | yes, SlickNik said he has two back to back hourly meetings at 2pm PDT. | 20:27 |
| SlickNik | amrith / rueben / iccha_: I'm free after 4 PDT today — and anytime tomorrow if that works better. | 20:28 |
| iccha_ | SlickNik: 4 PM works for me | 20:30 |
| *** achampion has quit IRC | 20:30 | |
| amrith | 7pm eastern is fine for me but I don't have a life ;) | 20:30 |
| amrith | let me check if dougshelley66 can also join us | 20:30 |
| rueben | iccha_: you guys feel free to meet up and I'll catch up on the details tomorrow :) | 20:31 |
| *** ViswaV_ has joined #openstack-trove | 20:32 | |
| *** yidclare has quit IRC | 20:32 | |
| *** ViswaV has quit IRC | 20:35 | |
| *** denis_makogon has quit IRC | 20:44 | |
| *** demorris has quit IRC | 20:45 | |
| openstackgerrit | Craig Vyvial proposed a change to openstack/trove: parse the mysql cnf file for password https://review.openstack.org/104107 | 20:46 |
| openstackgerrit | Craig Vyvial proposed a change to openstack/trove: guestagent contract for packages should be a list https://review.openstack.org/104108 | 20:47 |
| *** juantwo has quit IRC | 20:51 | |
| johnma | Are there any instructions available on how to setup a new datastore type in a redstack env. Currently I have a Legacy MySQL as the default and want to setup MySQL or MongoDB | 20:51 |
| glucas | johnma: the redstack kick-start command will create a guest image and set up a datastore | 20:52 |
| glucas | johnma: for example, ./redstack kick-start mysql | 20:52 |
| *** miqui has quit IRC | 20:53 | |
| johnma | Thank you so much glucas. Let me try that. What if I wanted to do the same for mongodb or any other type, could I do it through redstack as well? | 20:54 |
| *** ViswaV has joined #openstack-trove | 20:54 | |
| *** ViswaV_ has quit IRC | 20:55 | |
| SlickNik | johnma: I believe you can use the same command for mongodb as well. | 20:55 |
| johnma | Thank you SlickNik & glucas. appreciate it. I will give it a try | 20:57 |
| *** rueben has quit IRC | 20:58 | |
| SlickNik | johnma: One thing to remember is that the command updates the default datastore and version every time it's run, so the last run will define which datastore type is actually set up as the default one. | 20:58 |
| johnma | ok and is there another way to set the default to our like | 21:00 |
| *** jmontemayor has quit IRC | 21:01 | |
| *** nehav has quit IRC | 21:01 | |
| johnma | Thank you SlickNik. This has been very helpful. | 21:03 |
| *** iccha_ has quit IRC | 21:05 | |
| *** grapex_ has joined #openstack-trove | 21:06 | |
| *** grapex has quit IRC | 21:08 | |
| *** nehav has joined #openstack-trove | 21:08 | |
| *** yidclare has joined #openstack-trove | 21:12 | |
| *** jcru has quit IRC | 21:13 | |
| *** jcru has joined #openstack-trove | 21:13 | |
| *** Yogesh has quit IRC | 21:13 | |
| *** iccha has joined #openstack-trove | 21:18 | |
| *** Yogesh has joined #openstack-trove | 21:21 | |
| *** tvoran has quit IRC | 21:23 | |
| *** tvoran has joined #openstack-trove | 21:27 | |
| *** yidclare has quit IRC | 21:28 | |
| *** glucas has left #openstack-trove | 21:30 | |
| *** glucas has joined #openstack-trove | 21:31 | |
| *** iccha1 has joined #openstack-trove | 21:40 | |
| *** iccha has quit IRC | 21:40 | |
| *** iccha1 has quit IRC | 21:41 | |
| *** iccha has joined #openstack-trove | 21:46 | |
| *** nehav has quit IRC | 21:51 | |
| *** grapex has joined #openstack-trove | 21:54 | |
| *** grapex_ has quit IRC | 21:54 | |
| *** grapex_ has joined #openstack-trove | 21:56 | |
| *** grapex has quit IRC | 21:56 | |
| johnma | I ran the following command ./redstack kick-start mysql but when I run the trove command datastore-list I still see only 'Legacy MySQL'. Am i missing something here | 21:59 |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Make storage strategy available for trove API and TM https://review.openstack.org/86242 | 21:59 |
| esmute | johnma: it could be that the mysql datastore is not active | 21:59 |
| esmute | can you check the datastore_versions table ? | 22:00 |
| johnma | Thank you esmute. Can you show me how to verify the datastore_versions table. I am really new with trove | 22:01 |
| esmute | go to the trove database and check the datastores and datastore_versions tables | 22:03 |
| amrith | johnma, did kick-start mysql complete successfully? | 22:03 |
| esmute | either you datastore was not created propertly or they are not active | 22:03 |
| *** yidclare has joined #openstack-trove | 22:04 | |
| esmute | if you use an admin account, you should be able to see inactive datastore as well | 22:04 |
| johnma | amrith: it completed and it looks like there was no error but there wasnt anything that said it was successful either | 22:04 |
| *** michael-yu has quit IRC | 22:05 | |
| *** grapex has joined #openstack-trove | 22:05 | |
| esmute | if you dont see the datastore in the mysql table, the kick-start command probably didnt succeed. Can you gist the output of it? | 22:06 |
| *** grapex_ has quit IRC | 22:09 | |
| *** juantwo has joined #openstack-trove | 22:09 | |
| *** juantwo has quit IRC | 22:09 | |
| *** juantwo has joined #openstack-trove | 22:10 | |
| *** yidclare has quit IRC | 22:14 | |
| *** michael-yu has joined #openstack-trove | 22:16 | |
| *** robertmyers has quit IRC | 22:23 | |
| *** Yogesh has quit IRC | 22:26 | |
| *** Yogesh has joined #openstack-trove | 22:34 | |
| *** iccha has quit IRC | 22:39 | |
| *** jcru has quit IRC | 22:47 | |
| *** kevinconway has quit IRC | 22:48 | |
| *** amytron has quit IRC | 22:48 | |
| *** rhodgin has quit IRC | 22:48 | |
| SlickNik | johnma: if the command completed, you should have a mysql_ubuntu image in your glance catalog as well. Can you check the output of nova image-list to see if that image exists? | 22:49 |
| *** tvoran has quit IRC | 22:52 | |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Enable trove to specify cinder volume_type when creating a volume https://review.openstack.org/104370 | 22:54 |
| amrith | johnma, I have to assume that kick-start didnt' complete. | 23:01 |
| amrith | a mysql ubuntu image is created and installed as part of this. | 23:01 |
| amrith | so I have a question for SlickNik ... did your DIB changes get in? | 23:02 |
| *** mattgriffin has quit IRC | 23:02 | |
| SlickNik | amrith: Yes, they did. | 23:02 |
| amrith | remember that I had the same problem with building the image on a fresh trove-integration a couple of weeks ago? | 23:02 |
| SlickNik | why do you ask? | 23:02 |
| SlickNik | Yes, I recall. | 23:02 |
| *** iccha has joined #openstack-trove | 23:02 | |
| amrith | I had to make some change to trove-integration to make this work | 23:02 |
| amrith | what was it ... | 23:02 |
| amrith | page fault | 23:02 |
| amrith | page fault | 23:02 |
| amrith | page fault | 23:02 |
| iccha | SlickNik: amrith around? | 23:02 |
| * amrith runs away | 23:03 | |
| SlickNik | That change in trove-integration merged as well. | 23:03 |
| SlickNik | So if you get a fresh copy of trove-integration, you should be good. | 23:03 |
| amrith | so that isn't johnma's problem | 23:03 |
| amrith | I wonder then what it is | 23:03 |
| amrith | hi iccha | 23:03 |
| SlickNik | iccha: Am here. | 23:03 |
| amrith | SlickNik, I'm running review/nikhil_manchanda/bug/1329068 still. I should probably get to master | 23:04 |
| iccha | so just to be clear I am not against using capabilities for volume supprt :) | 23:04 |
| *** amcrn has quit IRC | 23:04 | |
| amrith | yup | 23:04 |
| amrith | i figured that | 23:04 |
| *** saurabhs has quit IRC | 23:04 | |
| amrith | my question is this | 23:05 |
| amrith | for what you are looking for, you want to know whether a particular datastore_version has volume support or not, is that right? | 23:05 |
| iccha | but it doesnt help that we do not have a clear plan for onboarding capabilities and two is that volume support is a special use case as well with an existing config value | 23:05 |
| *** amcrn has joined #openstack-trove | 23:05 | |
| amrith | or are you looking for a toggle at the datastore level? | 23:05 |
| iccha | for rackspace it is sufficient to toggle at datastore level | 23:06 |
| amrith | for the present use-case envisaged | 23:06 |
| amrith | I assume | 23:06 |
| iccha | yes | 23:07 |
| amrith | yes? | 23:07 |
| amrith | ok. | 23:07 |
| amrith | we said yes at the same time | 23:07 |
| amrith | OK, SlickNik ... I'm caught up | 23:07 |
| iccha | lol yes | 23:07 |
| amrith | it is apparent that capabilities isn't checked in and ready right now | 23:08 |
| amrith | oh, before I wander off | 23:08 |
| *** grapex has quit IRC | 23:08 | |
| amrith | I assume that use-case #1 is [redis], yes? | 23:08 |
| iccha | yes that is right amrith | 23:08 |
| *** saurabhs has joined #openstack-trove | 23:09 | |
| SlickNik | iccha: right, so if you add in the toggle in the config at the datastore level — there's nothing that precludes a "capabilities fallback" (when implemented) to make this discoverable via the API, and override it at a database level if needed, right? | 23:09 |
| iccha | if we do decide this to be a part of capabilities in future(which we did), we could still do that, it is just a queestion of where it would load the config value from | 23:09 |
| amrith | I guess I see a couple of issues. | 23:10 |
| amrith | 1. where will you load value from today? | 23:10 |
| amrith | 2. where will the value be loaded from in the future? | 23:10 |
| iccha | yes thats right SlickNik | 23:10 |
| amrith | 3. what is the migration strategy from 1 -> 2 | 23:10 |
| amrith | 4. There is code change required, who will do that? | 23:10 |
| iccha | 1. from config file [mysql]volume_support . (wiki page for example) | 23:10 |
| iccha | 2. from capabilities database, if value not present there will default to config value | 23:11 |
| iccha | 3. there is no need for migration, since database will be the first look up, only if value is not present will the config value be used | 23:11 |
| amrith | <waiting for you to finish> | 23:12 |
| iccha | 4. it would be more of code addition, based on what we decide as a community to be our capabiltieis addition strategy | 23:12 |
| iccha | why i say that is because we want the capability names to be consistent across deployers | 23:12 |
| iccha | go ahead amrith | 23:12 |
| amrith | re: 1. would you be implementing code for all datastores? or just the one you want in this case <will wait for answer> | 23:12 |
| iccha | 1. it would be for all datastores . every [datastore] would have this config value volume_Support. if not present will default to global config value trove_volume_support | 23:13 |
| iccha | we will load it in as config[datastore].volume_support | 23:14 |
| *** Yogesh has quit IRC | 23:14 | |
| amrith | if I may, then the view is that in the future you wouldn't move this to capabilities as you'd assume the fallback. (2 and 3) | 23:15 |
| amrith | would that mean that config[datastore].volume_support must first read capabilities and then config? | 23:15 |
| amrith | <eot> | 23:15 |
| SlickNik | amrith: That actually depends on how capabilities is actually implemented. There was some talk at the mid-cycle meetup of extending the CONF object to check if a capability exists in the DB and return that, and only fallback to the CONF if a DB value doesn't exist. | 23:16 |
| iccha | SlickNik: was there any discussion on how to add have consistency of capability names across deployers | 23:17 |
| amrith | SlickNik, that was effectively my question. Was iccha assuming this implementation. | 23:17 |
| iccha | amrith: i did not even know about this implementation till SlickNik mentioned it in today's meeting | 23:17 |
| amrith | I'm trying at some level to disentangle configurations from capabilities (call them feature 1 and feature 2 because the names are confusing) | 23:17 |
| iccha | i did not find any documentation in the wiki about this plan | 23:17 |
| iccha | amrith: SlickNik did yall have a chance to take a look at how i envisioned capabilties without the config stuff in the wiki? | 23:18 |
| amrith | so iccha you are correct, I've been reading about this over the past couple of days and it is clear that the bp needs some work. | 23:18 |
| SlickNik | iccha: I looked as well, and the documentation is lagging behind the discussions we had :( | 23:19 |
| amrith | iccha, please clarify question. what you mean, is there a specific doc you refer to ... | 23:19 |
| SlickNik | iccha: Nope been in meetings and haven't had a chance to look that over. | 23:19 |
| SlickNik | Can you link it here? | 23:19 |
| iccha | amrith: SlickNik its a small read the capabilities section in this https://wiki.openstack.org/wiki/Trove/trove-per-datastore-volume-support | 23:20 |
| amrith | A quick read of this gives me some concern(s). let me type them out here ... there are a couple. | 23:21 |
| amrith | first, it is prescriptive in its interpretation of how capabilities should work, such as the fact that migration should add a row to a table. what if a row doesn't exist, how should code behave? | 23:22 |
| amrith | second, is there a list of capabilities and adding one that isn't on the list is a cardinal sin? | 23:22 |
| iccha | yes its totally wrong, i am not saying we implement it | 23:22 |
| amrith | third, that calls made by operators/deployers to add a version overrides a "table", whatever that happens to be ;) | 23:22 |
| iccha | i am trying to highlight the consistency across deployers | 23:23 |
| iccha | because u are going to be checking for that capability name in the code | 23:23 |
| iccha | there in no protocol | 23:23 |
| iccha | that is a concern | 23:23 |
| iccha | hence we need a fall back | 23:23 |
| amrith | ok, iccha let me ask this then. | 23:23 |
| iccha | like the config value | 23:23 |
| *** saurabhs has quit IRC | 23:24 | |
| amrith | the way a value gets in a config value (in a file) is either (i) it is in the standard template or (ii) someone types it in. These are the exact same ways in which something gets into capabilities. Either they are in a migration script or someone types them in. What new risks have we added in this process? I see none. | 23:24 |
| amrith | <over> | 23:25 |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Make storage strategy available for trove API and TM https://review.openstack.org/86242 | 23:25 |
| iccha | ok fair enough, but is there any harm in trying to be more robust or having defaults? | 23:26 |
| iccha | <over> :p | 23:26 |
| amrith | hey, I'm a ham radio operator, I do this over thing in morse code regularly ... | 23:27 |
| amrith | but, no, there's nothing wrong | 23:27 |
| amrith | I just highlight the fact that capabilities are not inherently more risky in terms of a missing protocol than a config file | 23:27 |
| amrith | and therefore the discussion of more robust should be had in that context, not of improvement of one over the other but overall improvement. | 23:28 |
| amrith | de k1ann | 23:28 |
| amrith | <over> | 23:28 |
| vipul | if you're going to fallback to reading the capability from a Conf, it seems like you're restricted in the capability name regardless, you have to know what the 'key' is going to be when you look in the conf. So it seems to me that it needs to be introduced as a 'key' in the Conf, and then deployers have the choice of "promoting" it to a capability, hence exposing its value over an API | 23:29 |
| SlickNik | vipul, either that, or having a mapping in the capability itself mapping it to a conf value for fallback. | 23:29 |
| iccha | yes we need some standardization | 23:30 |
| vipul | Yea you could do that.. i guess i don't see what value there would be in mapping a CFG entry to another key | 23:30 |
| vipul | so if we have volume_support as the cfg item in a conf file.. the capability better be named 'volume_support' as well in the DB | 23:30 |
| *** thedodd has quit IRC | 23:31 | |
| SlickNik | So I think, the capabilities bp as it stands today is a bit over-engineered for my liking. I'd totally be fine with a v1 API that just discovers the value of a cfg param through the API, and I suspect this would suffice for the horizon requirement. | 23:31 |
| amrith | SlickNik, yes and no | 23:32 |
| iccha | +1 about the over engineering | 23:32 |
| amrith | so here's why I'm opposed to config files as a "repository of truth". You have many machines each with a config file and pretty soon you have a management nightmare. A single point (database) is a better solution. No, I don't think we should implement file rsync as a mechanism to keep config files synchronized in trove ;) | 23:33 |
| amrith | at a high level, a datastore [redis] could have many datastore_version entries. | 23:34 |
| amrith | some may want volume support, others may not | 23:34 |
| SlickNik | amrith: Sometimes you do want different components files on different machines to have different configs. | 23:34 |
| amrith | my concern is that in the drive to get this done for volume_support, we are not implementing a solution that should be adopted across the board. | 23:34 |
| amrith | SlickNik, tying difference in files to a specific machine is a sure way to get divergent files and not something which scales horizontally in a large configuration. I'd bet that if a large deployment had two machines with a different configuration file, they'd call these two machines "differetn flavors". | 23:36 |
| iccha | amrith: thats why we have puppet and chef to help with config deployments | 23:36 |
| amrith | iccha, that's not a solution that is "product friendly", unfortunately. | 23:37 |
| iccha | thats a bigger question to tackle config vs database values | 23:37 |
| SlickNik | amrith: And the way configs are handled across OpenStack are through config files and not thought a config database (not saying right or wrong just stating how it is today across different OpenStack components). | 23:37 |
| amrith | so what do you folks suggest? | 23:38 |
| amrith | how should we proceed? | 23:38 |
| amrith | it is certain to me that the capabilities BP needs rework | 23:38 |
| iccha | I think we should not hold up current features because we are still trying to figure out capabilities | 23:38 |
| amrith | it is also unclear how people would adopt it from the perspective of "standardization" unless we can mandate that the CONFIG API wrap capabilities. | 23:38 |
| amrith | iccha, that's a slippery slope and I'd rather not use taht particular phraseology for a bunch of reasons. | 23:39 |
| amrith | but be that as it might | 23:39 |
| amrith | there is a desire to implement volume_support | 23:40 |
| iccha | which phrase amrith ? | 23:40 |
| amrith | the phrase "holding up current features because we are trying to figure out capabilities". | 23:40 |
| amrith | or that sentiment | 23:40 |
| amrith | anyway, moving past that | 23:40 |
| amrith | there is a desire to implement volume_support | 23:40 |
| amrith | and there is no clear indication whether there is support for capabilities | 23:41 |
| amrith | I thought there was, but that appears to be somewhat questionable at this point. | 23:41 |
| amrith | so what do you folks suggest, how should we proceed? | 23:41 |
| amrith | OK, no takers on a plan? | 23:42 |
| amrith | I'll even say <over> | 23:43 |
| amrith | <over> | 23:43 |
| * SlickNik is furiously typing | 23:43 | |
| iccha | I suggest we add them to config values per datastore for now as a starting poiny | 23:43 |
| amrith | I'm happy to offer one | 23:43 |
| * iccha waits for SlickNik | 23:43 | |
| vipul | I wouldn't want to say this feature must be implemented as a capability, especially since it doesn't exist. I think this exercise of going through and talking about whehther it could be implmented by capabilities.. was meaningful -- and it seems that if we go with a conf based fallback -- it would naturally fit in once that fallback is implemented | 23:43 |
| * amrith runs to refrigrator | 23:43 | |
| SlickNik | I think that it's fair to suggest that folks who need to extend the conf be allowed to do so. | 23:44 |
| SlickNik | And that when we implement capabilities, we do so in such a way that there is a path allowing "promotion" of a config value to a capability (either seamlessly, or by adding code). | 23:44 |
| SlickNik | Then the onus of whether a config option should be a capability by default (or not) can be tackled specifically depending on whether it makes sense to do so — and whether deployers actually want to promote it. | 23:44 |
| iccha | +1 | 23:44 |
| vipul | yep, i'm good with that SlickNik | 23:44 |
| amrith | so I'm not | 23:45 |
| amrith | and here's the other side of it. | 23:45 |
| amrith | when the product (trove) is shipped, or downloaded, what does it expect in a database and what does it expect in a configuration file? | 23:45 |
| amrith | it is fine and dandy for operator A to go stick volume_support in a file and say it is all done. | 23:46 |
| amrith | But what of the user who downloads the product? | 23:46 |
| vipul | I think it's the same problem as datastores.. | 23:46 |
| amrith | if I were to follow SlickNik's path down the road there would be furious cries of resistance if I were to decide that a migration script to add a value for volume_support into the database! | 23:46 |
| vipul | a deployer today has to go in and add the datastores that they want to support | 23:46 |
| vipul | imo, it's a documentation exercise.. if you want to expose conf params, promote them | 23:47 |
| vipul | if we want to be nice -- we can have a migration script that seeds the initial 'we all agree upon' items | 23:47 |
| amrith | so in effect, the flaw in SlickNik's logic is the fact that by allowing the present "extension", you have effectively precluded a product default (through a capability) for the value specified in this "extension". And I see vipul say this is a "documentation exercise", sorry, that won't scale! | 23:47 |
| esmute | amrith: Isnt a user who downloads the product also be an operator? I mean, that user would have to know how to config trove propertly to work | 23:47 |
| amrith | esmute, yes, it could be an operator. My question is this, what are the "defaults" for the system? | 23:48 |
| amrith | or are you stipulating that Trove shall ship with NO, NONE, ZERO, ZIP, NADA defaults | 23:48 |
| vipul | the defaults exist in the conf | 23:49 |
| amrith | and the user or operator has to configure them all, each and every one | 23:49 |
| iccha | amrith: is that not an issue with any of the current config values? | 23:49 |
| SlickNik | amrith: So a default exists, and it's in the config file. If you as a deployer want to programmatically change the default via the API, go ahead and enable it as a capability by all means. | 23:49 |
| iccha | what about trove_support_volume? | 23:49 |
| esmute | shouldnt the default be the config values that we are currently testing in our CI... eg trove_volume_support enabled | 23:49 |
| amrith | iccha, yes it is. Hence the issue of migration and capabilities. If we're opposed to the notion of migration to capabilities, we may as well kill capabilities and do everything in conf files! | 23:49 |
| iccha | we could default the volume_support to the global config value/default | 23:49 |
| iccha | of trove_support_Volume | 23:49 |
| amrith | iccha, SlickNik, esmute ... I think you are all talking past my point, let me try and illustrate again. | 23:50 |
| amrith | case #1 | 23:50 |
| amrith | a system that currently is configured with a particular "value" in a configuration file. | 23:51 |
| amrith | this is a good and well known "value" and default is established. | 23:51 |
| amrith | Most people agree with the default, some tweak it. | 23:51 |
| amrith | But, it is in a configuration file. | 23:51 |
| amrith | Along comes the new capabilities feature | 23:51 |
| amrith | A new trove is created | 23:51 |
| openstackgerrit | Anna Shen proposed a change to openstack/trove-integration: Add support for a neutron-based install https://review.openstack.org/78123 | 23:51 |
| amrith | it ships with two things now, a sample config file and a database script to see initial values. | 23:52 |
| amrith | where would this new trove put the default value for "value"? | 23:52 |
| SlickNik | amrith: I'm saying that it wouldn't need a database script. | 23:52 |
| amrith | question #2 related to this, how does a migration handle a configuration file. | 23:52 |
| vipul | If we're seeding the databse.. then obviously the database would ge the value | 23:52 |
| amrith | does it pick it up from the config file and jam it in a database or not? | 23:52 |
| amrith | Case #2 a brand new system | 23:53 |
| amrith | What's it's default | 23:53 |
| SlickNik | amrith: We don't need to do that (and really shouldn't) if we fall back to the config file. | 23:53 |
| amrith | where does the default come from? a config file or a database | 23:53 |
| esmute | i think we should not have any value in the database... because it will fallback on the config.. | 23:53 |
| *** shayneburgess has quit IRC | 23:53 | |
| esmute | config file | 23:53 |
| amrith | so esmute you decree that it is the user's (operator or end user) responsibility to make sure that in a multi-machine configuration that the right configuration files move to each machine. | 23:54 |
| vipul | So when capabiliies are implemented, we can choose to have a migration script that seeds the 'initial' capabilties that we think all deployers should support.. that might include volume_support among other things | 23:54 |
| vipul | if we do that -- then it solves both cases, there will be default values in the database, regardless if it's a new trove, or exisiting | 23:54 |
| amrith | it was one of the things that I thought to be the goal of the capabilities project ... to avoid this file sync'ing problem. | 23:55 |
| amrith | no vipul, it doesn't solve it | 23:55 |
| esmute | correct me if im wrong but i think when a brand new trove is deployed, the database (capabilities) is empty.. and trove will get its config from the config file.... The user can set his/her capabilities in the DB | 23:55 |
| amrith | because if I put default volume_support = true, iccha will be unhappy ;) | 23:55 |
| vipul | amrith: it's a default.. if she's unhappy, she can change the default in the db | 23:56 |
| *** saurabhs has joined #openstack-trove | 23:56 | |
| vipul | same as what you'd have to do if it was a conf file | 23:56 |
| esmute | iccha is a she? | 23:56 |
| iccha | yeah the deployer needs to be aware of whats going in a release | 23:57 |
| esmute | :p | 23:57 |
| SlickNik | So if a deployer wants to change the value in the config file, two scenarios exist. | 23:57 |
| SlickNik | 1. He wants to do it once and has access to the config file: He updates the config file, restarts the service - done. | 23:57 |
| SlickNik | 2. He wants to be able to programmatically update the value via the API whenever makes sense: Create an override value for the config in the database, and trove picks that value over the config file value. | 23:57 |
| amrith | SlickNik, you are prescribing that defaults shall not be distributed through a database script. | 23:57 |
| amrith | in effect, you are advocating what esmute said | 23:58 |
| amrith | and not what vipul said | 23:58 |
| iccha | SlickNik: i like that! and can further override it with capabiltites override | 23:58 |
| amrith | vipul said ... "there will be default values in the database, regardless if it's a new trove, or exisiting" | 23:58 |
| vipul | I think it's probably sane to seed initial capabilities.. and this would be part of the capabilities implementation | 23:58 |
| amrith | vipul, where? | 23:58 |
| amrith | in conf or in db? | 23:58 |
| vipul | in the DB.. seed = db migration | 23:59 |
| iccha | to insert a row | 23:59 |
| iccha | similar to what was in docs i had | 23:59 |
| esmute | the initial values for capabilities should be what is in the config then? Maybe i dont see the point of seeding capabilities | 23:59 |
| iccha | yes esmute ! | 23:59 |
| amrith | so SlickNik maybe I should summarize (as I'm going to be pointing dougshelley66 at this in the AM) | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!