Thursday, 2015-02-19

« Wednesday, 2015-02-18 Index Friday, 2015-02-20 »
*** miqui has quit IRC01:01
*** charlesw has joined #magnetodb01:07
*** ajayaa has joined #magnetodb01:29
*** ajayaa has quit IRC01:38
*** achanda has quit IRC02:33
*** achanda has joined #magnetodb02:42
*** achanda has quit IRC02:46
*** achanda has joined #magnetodb03:02
*** achanda has quit IRC03:45
*** achanda has joined #magnetodb03:52
*** achanda has quit IRC04:16
*** miqui has joined #magnetodb04:42
*** miqui has quit IRC04:52
*** miqui has joined #magnetodb04:53
*** achanda has joined #magnetodb05:16
*** achanda has quit IRC05:18
*** achanda has joined #magnetodb05:18
*** charlesw has quit IRC05:22
*** achanda has quit IRC05:45
*** achanda has joined #magnetodb05:56
*** miqui has quit IRC06:26
*** vivekd has joined #magnetodb07:16
*** vivekd has quit IRC07:37
*** achanda has quit IRC08:29
*** achanda has joined #magnetodb08:29
*** achanda has quit IRC08:30
*** rushiagr_away is now known as rushiagr08:52
*** vivekd has joined #magnetodb08:53
*** ygbo has joined #magnetodb09:23
*** vivekd_ has joined #magnetodb10:56
*** vivekd has quit IRC10:57
*** vivekd_ is now known as vivekd10:57
*** rushiagr is now known as rushiagr_away11:54
aostapenkoGuys, if you have something to say on meeting update agenda please https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda12:58
openstackgerritDmitriy Ukhlov proposed stackforge/magnetodb: Migrate custom local secondary indices to Cassandra 2.1.2  https://review.openstack.org/15251313:11
aostapenkoHi, gyus!14:02
aostapenkoduklov, ikhudoshyn, isviridov_vction, vivekd meeting is starting14:03
dukhlovhello, aost14:03
aostapenko*dukhlov14:03
dukhlovI so sorry, aostapenko14:03
aostapenko#startmeeting magnetodb14:03
openstackMeeting started Thu Feb 19 14:03:43 2015 UTC and is due to finish in 60 minutes.  The chair is aostapenko. Information about MeetBot at http://wiki.debian.org/MeetBot.14:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:03
openstackThe meeting name has been set to 'magnetodb'14:03
aostapenko#topic action items14:04
aostapenkodukhlov, how is your investigation about moving to cassandra 2.1.214:06
dukhlovstill in progress14:06
dukhlovI am trying to narrow scope of problem14:08
dukhlovnow I can reproduce it with only one cassandra node, even with consistency level ALL14:08
dukhlovalso I removed async task executor14:09
dukhlovand use SimpleStorageManager14:09
dukhlovinstead14:09
dukhlovI'm going to create a bug in cassandra project14:10
dukhlovso that is it14:10
aostapenko#action dukhlov create a bug in cassandra project related to issue about moving to C* 2.1.214:11
aostapenkook, thank you very much14:12
aostapenkovery appreciate14:12
dukhlovawesome14:13
aostapenkoDo you need any assistance? me or charlesw could try to help14:13
dukhlovA'm going to take vacation next week14:14
dukhlovyou could continue my work if I will not manage to finish it14:15
aostapenkook, I'll get into the swing of things14:16
aostapenkoAnything else you are working on?14:17
dukhlovunfortunately not14:18
*** charlesw has joined #magnetodb14:18
dukhlovbecause of lack of my time14:19
aostapenkodukhlov what do you think about backup blueprint https://blueprints.launchpad.net/magnetodb/+spec/backup-restore14:19
dukhlovI think it is very useful feature14:20
aostapenkoikhudoshyn have no ability to finish it14:20
dukhlovah, got it14:20
aostapenkoMaybe you could look what is need to be done14:20
aostapenkocharlesw, Hi14:20
charleswHi guys14:20
dukhlovIt looks like it lose the priority14:21
dukhlovAm I wrong?14:21
aostapenkoblueprint has high priority, and much code is in repo already14:22
aostapenkoso I suggest not to drop it14:22
aostapenkoand do at least simple implementation14:23
charleswI would think the migration utility is more urgent14:24
aostapenkocharlesw: could you adopt it?14:24
dukhlovthat is good but who will take care about it?14:24
charleswIt's WIP. We need to understand what's missing, and what the remaining work is?14:25
charleswAnd same thing with the table metrics14:25
aostapenkoAs I understand we have a lack of resources14:26
aostapenkoSo I suggest to share this blueprints between dukhlov and charlesw14:27
charleswcan you help us understand what the gap is?14:28
dukhlovI can take backup/restore after vacation14:29
aostapenkoGreat, dukhlov14:30
aostapenkoI'll assign it to you14:30
charleswI'll take the other two14:30
charleswbut I need help understanding the gaps14:30
aostapenkoGreat14:31
aostapenkohttps://blueprints.launchpad.net/magnetodb/+spec/migration-script14:32
aostapenkohttps://blueprints.launchpad.net/magnetodb/+spec/statsd-tables-metrics14:32
aostapenkohttps://blueprints.launchpad.net/magnetodb/+spec/backup-restore14:32
aostapenkolets move on14:33
aostapenkocharlesw, what about "Create a blueprint on periodically convert healthcheck API call results to metrics"14:33
charleswI looked at the table metrics blueprint. They are similar. I was think we need to have a general approach instead.14:34
charleswtable metrics spec was saying the daemon is an add-on service, in contrib maybe14:35
aostapenkocharlesw, could you add it to existing blueprint or create a new dependent one?14:35
charleswBut do we really need to go with that approach?14:36
charleswI would think once the statsd metrics patch is merged, we can just have an optional service in core MagnetoDB14:36
charleswinstead of having a separate service, which adds to the complexity of deployment14:37
charleswSay we have a periodic task runner in MagnetoDB API server, which can run any task at any interval. We don't need to deploy another separate service14:40
dukhlovIt should be some background task14:40
dukhlovwill it be deamon or periodic task runner it  MagnetoDB API server it is another question14:41
dukhlovand it can be different depend on deployment14:41
charleswAlso the current approach of going thru rest API will have the problem of Keystone authn and authz14:42
dukhlovbut we should provide API for that deamon/async task14:43
charleswfor what purpose? to configure interval/tasks?14:43
dukhlovAlso the current approach of going thru rest API will have the problem of Keystone authn and authz, it is not fully true, we can disable authentification14:43
charleswIt will have to pass policy check14:44
charleswAM I missing something?14:44
dukhlovok, I 'm personally not sure that async job in scope of MagnetoDB server process is good Idea14:45
dukhlovbut ew can do it fi we have api14:45
dukhlovbecause move it to deamon is easy14:45
charleswI'm not sure if I fully understand what you mean by api?14:45
dukhlovmonitoring rest API for getting table metrics14:46
dukhlovIt will have to pass policy check - it is up to us14:47
charleswI'd say statsd is the way to go in general, instead of API14:47
charleswIf we just do statsd without API, we won't have such problems.14:48
dukhlovstatsd is quite different thing as far I understant14:48
dukhlovstatsd is passive service. It waits for notifications14:49
charleswThat's why we need periodic task runner to send notifications14:50
dukhlovok, I agrree but how this periodic task will get information about table metrics14:51
dukhlov?14:51
charleswYou can either call storage manager directly, or go thru API layer with an internal special role14:52
*** richard has joined #magnetodb14:52
*** richard is now known as Guest734214:53
aostapenkoI prefer an old approach thru the monitoring api14:54
dukhlovAt least we have it already and i think it is not resonable to remove it14:55
aostapenkodukhlov, agree14:55
dukhlovbut you can use storage manager directly if your async task works as pasrt of magnetodb14:55
charleswIt wouldn't work for our use cases14:55
dukhlovwhy?14:56
charleswwe need statsd metrics14:56
charleswto integrate with our monitoring system14:56
dukhlovstatsd metrics it is another part14:57
dukhlovthe question where to locate async task14:58
charleswone question, the monitoring API, what kind of keystone authn do we need?14:59
dukhlovit is fully configurable14:59
dukhlovwe can fully disable it15:00
charleswCan anybody use the monitoring API to find out table metrics?15:00
dukhlovanybody from internal network15:01
aostapenkocharlesw, monitoring requests should be forbidden externally15:01
charleswwithout authn?15:02
dukhlovyes15:02
aostapenkothat was an idea15:02
charleswsounds like a security hole15:02
charleswIf we use statsd metrics, we won't have such issue15:03
dukhlovwe have the same issue15:03
dukhlovbecause cassandra port is open for whole intenal network15:04
charleswWe will have to fix that later15:04
dukhlovhow?15:04
charleswWe can't use that as an excuse to add more vulability15:04
charleswusing ssl, user name/password, etc15:05
aostapenko#action duklov, charlesw, aostapenko make a decision about monitoring system15:06
aostapenkoWe are out of time, we can continue a discussion after the meeting in this channel15:06
aostapenko#endmeeting15:07
openstackMeeting ended Thu Feb 19 15:07:02 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:07
openstackMinutes:        http://eavesdrop.openstack.org/meetings/magnetodb/2015/magnetodb.2015-02-19-14.03.html15:07
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2015/magnetodb.2015-02-19-14.03.txt15:07
openstackLog:            http://eavesdrop.openstack.org/meetings/magnetodb/2015/magnetodb.2015-02-19-14.03.log.html15:07
charleswthanks andrei15:07
aostapenkoThank you, charlesw15:07
aostapenkoThanks, guys15:07
aostapenko!m dukhlov15:07
[o__o]You're doing good work, dukhlov!15:07
openstackaostapenko: Error: "m" is not a valid command.15:07
dukhlovfor monitoring api we can use https too, we can implement authentification using admin_user or so on15:09
dukhlovbut maybe you are right15:10
charleswadmin_user in keystone?15:10
dukhlovyes15:10
charleswadmin_user for all tenants?15:10
charleswand all domains?15:11
dukhlovit is our code15:11
dukhlovwe can do everything15:11
dukhlovwhat is the better way - is point of discussing15:12
charleswBut we need to conform to the standard security practice15:12
dukhlovwhat is standard security practice for getting access to all tenants?15:13
charleswNo way I can think of15:13
charleswfor all domains15:14
charleswSo using statsd is a good way to bypass the problem15:14
dukhlovusing statsd you just don't use any authentification15:19
dukhlovstatsd will have information about table metrics15:20
charleswtrue15:20
dukhlovand how to control access to statsd then?15:20
charleswyou rely on the monitoring framework's own security to handle this15:21
charleswfor example, statsd can use ssl to ship metrics to monitoring server, and/or add user/password15:22
charleswmonitoring server can define roles to let different users to control access to metrics15:23
*** Guest7342 has quit IRC15:24
dukhlovI have no objections about your idea15:25
dukhlovI only keep in mind that it is only one way of deployment15:26
dukhlovbut another way is active monitoring server for example which request metrics itself, maybe when user press update button15:28
charleswI'm open to alternatives. So far this seems a more reasonable approach15:28
dukhlovand monitoring api will be reqired for this15:28
charleswpull vs push15:29
dukhlovfor your suggestion I see only one open question where to locate async task runner15:30
charleswLook at the proven approaches: in Java, there's JMX - push, in openstack world, statsd - push15:31
charleswI call it periodic task runner, not async :)15:31
dukhlovok, periodic15:33
*** achanda has joined #magnetodb15:33
dukhlovJMX is pull15:34
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Updated tempest revision  https://review.openstack.org/15741515:34
dukhlovstatsd - I don't know it but from your words I understood that it can work in both mode.15:35
dukhlovI'm talking now about metrics provider15:36
dukhlovbut statsd is rather metrics brocker15:36
dukhlovbecause we need to push metrics from the first side and pull(maybe it can push it forward) to second side15:37
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Updated tempest revision  https://review.openstack.org/15741515:39
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Updated tempest revision  https://review.openstack.org/15741515:40
*** vivekd has quit IRC15:41
*** achanda has quit IRC15:41
charleswdukhlov, aostapenko, let me write up a new blueprint so we can review and comment in gerrit, is that ok?15:44
aostapenkocharlesw, yes, please15:44
dukhlovok, sure15:45
charleswwill do, thx15:46
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Fixes query documentation  https://review.openstack.org/15742515:55
*** openstackgerrit has quit IRC16:36
*** openstackgerrit has joined #magnetodb16:36
*** ygbo has quit IRC16:46
*** charlesw has quit IRC17:06
*** charlesw has joined #magnetodb17:09
*** charlesw has quit IRC17:15
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Updated tempest revision  https://review.openstack.org/15741517:17
openstackgerritAndrei V. Ostapenko proposed stackforge/magnetodb: Sets ampq durability to default  https://review.openstack.org/15543318:05
*** charlesw has joined #magnetodb18:06
*** achanda has joined #magnetodb18:31
openstackgerritCharles Wang proposed stackforge/magnetodb: Add check for non-existing table internal name for delete table  https://review.openstack.org/15680619:00
*** achanda has quit IRC19:11
*** achanda has joined #magnetodb19:34
openstackgerritCharles Wang proposed stackforge/magnetodb: Add check for non-existing table internal name for delete table  https://review.openstack.org/15680620:27
*** achanda has quit IRC20:28
*** achanda has joined #magnetodb20:32
*** miqui has joined #magnetodb20:44
*** achanda has quit IRC21:06
*** achanda has joined #magnetodb21:24
*** achanda has quit IRC21:40
*** achanda has joined #magnetodb21:46
*** openstackstatus has joined #magnetodb22:14
*** ChanServ sets mode: +v openstackstatus22:14
openstackgerritMerged stackforge/magnetodb: Fixes query documentation  https://review.openstack.org/15742522:28
*** charlesw has quit IRC22:39
*** miqui has quit IRC23:29
« Wednesday, 2015-02-18 Index Friday, 2015-02-20 »

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!