Wednesday, 2014-10-29

*** rushiagr is now known as rushiagr_away00:20
*** charlesw has joined #magnetodb01:10
*** vnaboychenko has quit IRC01:41
*** vnaboychenko has joined #magnetodb02:21
*** charlesw has quit IRC03:47
*** jeromatron has joined #magnetodb04:14
*** vnaboychenko has quit IRC04:15
*** jeromatron has quit IRC05:25
*** jeromatron has joined #magnetodb05:25
*** rushiagr_away is now known as rushiagr05:29
*** jeromatron has quit IRC05:32
*** vivekd has joined #magnetodb06:11
*** rushiagr is now known as rushiagr_away08:27
*** k4n0 has joined #magnetodb08:28
*** rushiagr_away is now known as rushiagr08:39
*** romainh has joined #magnetodb08:43
*** ajayaa has joined #magnetodb08:46
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: Moves passing tempest tests to stable directory  https://review.openstack.org/13146409:43
*** vivekd has quit IRC09:46
*** vivekd has joined #magnetodb09:47
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Forbid PUT and DELETE of same item in batch write  https://review.openstack.org/13138409:49
*** ajayaa has quit IRC10:34
isviridovHello everybody10:34
*** rushiagr is now known as rushiagr_away10:39
openstackgerritA change was merged to stackforge/magnetodb-specs: Cassandra implementation of monitoring api  https://review.openstack.org/13080110:39
ominakovisviridov, hello10:55
isviridovominakov : hey10:55
isviridovominakov : great job http://magnetodb-specs.readthedocs.org/en/latest/10:56
isviridov!m ominakov10:56
[o__o]You're doing good work, ominakov!10:56
openstackisviridov: Error: "m" is not a valid command.10:56
isviridovachudnovets : around?10:56
isviridovominakov : are you working on monitoring of Cassandra?10:59
isviridovI mean is it you or achudnovets. Becauseaccording to API specs we have to updated implementation with support metric names11:00
ominakovisviridov, yep, now i'am updating documentation and i think i'll can update implementation (because achudnovets is ill now)11:02
ominakovisviridov, what do you think about this?11:02
isviridovominakov : sounds great!11:03
*** ajayaa has joined #magnetodb11:06
*** ajaya has joined #magnetodb11:07
*** boris-42 has quit IRC11:11
isviridovHello ajaya11:12
ajayaHi isviridov.11:15
*** ajaya has quit IRC11:16
*** ajaya has joined #magnetodb11:16
isviridovajaya : how was your festival?11:20
ajayaisviridov, It was awesome. :)11:20
ajayaHow did you know it was a festival?11:20
isviridovrushiagr said me11:21
ajayaisviridov, okay.11:21
isviridovI wanted to talk to your about integration with celiometer11:22
isviridovDo you have some time?11:22
ajayaisviridov, yes.11:22
openstackgerritA change was merged to stackforge/magnetodb: Additional validation; UUIDs as internal table names  https://review.openstack.org/12544511:22
* isviridov trying to find patch with spec11:23
isviridovYeap, here it is https://review.openstack.org/#/c/126335/11:24
*** rushiagr_away is now known as rushiagr11:25
ajayaisviridov, When I proposed that spec, I thought metering is going to be done by sending notifications to ceilometer.11:25
isviridovI've looked at it, and have several suggestions, but first it is only about notifications processing, what about polster driven implementation?11:25
isviridovajaya : aha do you think different now?11:26
ajayaisviridov, Yes.11:27
ajayaIf for each api call a notification is generated, then we will overwhelm message bus and ceilometer also.11:27
ajayaisviridov, For pollster driven implementation, I need to talk to ceilometer team.11:28
isviridovOk, great to know that we are on the same page now.11:28
isviridovHowever, I would suggest splitting the integration into two parts, as far as polster driven implementation should be agreed in advance.11:28
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Forbid PUT and DELETE of same item in batch write  https://review.openstack.org/13138411:29
ajayaCan you please tell me what you have in mind for these two parts?11:29
isviridovNow I see that we can monitor table count  per tenant  (table crete/delete events) via notifications.11:31
ajayaisviridov, +111:32
isviridovAlso we have 2 other metrics for now - table size and count items in table. It will be exposed via monitoring api11:33
isviridovHere it is http://magnetodb-specs.readthedocs.org/en/latest/specs/kilo/approved/monitoring-api.html11:33
isviridovThe implementation for C* is on its way11:34
isviridovHere I think the polster approach would be better.11:34
ajayaisviridov, We will need a pollster implementation to send data from monitoring api to ceilometer.11:34
ajaya+111:34
isviridovajaya : actually to poll data by celiometer from mdb monitoring api11:35
ajayaisviridov, okay.11:36
ajayaThere are a lot of other metrics which will be collected by various daemons.11:37
ajayaWhere do you plan to store them?.11:37
isviridovWhat daemons do you mean?11:37
ajayaisviridov, Something like cpu load, network IO measured by daemons.11:39
isviridovajaya : why do we need it in celiometer?11:39
ajayaisviridov, Do you think only table count and bytes used by a table are sufficient for metering and billing?11:40
isviridovWhat I mean to say, mdb is service and internal state of infrastructure shouldn't be exposed to user.11:41
ajayaisviridov, agree.11:41
isviridovI think we have to extend the list, but wil meaninful data, granulated by user/project/tenant11:42
ajayaisviridov, We need to measure the request count and bytes scanned per request etc.11:42
isviridovSo, technically it likely will be internal mdb counters, than infrastructure monitoring.11:42
openstackgerritOleksandr Minakov proposed a change to stackforge/magnetodb: Adds documentation on monitoring API  https://review.openstack.org/13116511:42
ajayaisviridov, Yes. We can maintain an internal counter and ceilometer could se it.11:43
ajaya*use it.11:43
isviridovajaya : yes. Do you have a list came from your/your customer/your company  usecases?11:44
isviridovHere it is for Symantec https://docs.google.com/a/mirantis.com/spreadsheets/d/1tYvgCSvkcOVED46MX8qSlUyrhNhHlyTrVkX7AXP-XR4/edit#gid=011:44
ajayaisviridov, I don't have a list.  This document came up in one of the weekly meetings.11:45
isviridovJust look at Data destination = Ceilometer/Billing solution11:45
isviridovajaya : yeap, but in order to imlement anythin it is needed to see the priorities first. And I personally believe the best way to set the priorities is to listen to users :)11:46
ajayaisviridov, +111:47
isviridovOk, what are your plans about ceilo+mdb?11:48
ajayaisviridov, Notifications are easy to implement and I have an idea of what to do in ceilometer.11:49
ajayaI need to check with ceilometer guys for pollster driven implementation.11:50
isviridovajaya : Let me do it myself first, I believe it would be easier for me.11:51
isviridovI mean before sharing the idea to ceilo community, it would be nide to discuss it pesonally to make it better and easier accepted11:52
isviridov* nice11:52
ajayaisviridov, okay. I am fine with it. :)11:52
ajayaYou have Dina Belova in mirantis who is ceilometer core. :)11:53
isviridovI would suggest you finish with spec and update the blueprint as well https://blueprints.launchpad.net/ceilometer/+spec/support-magnetodb. With clear pointing to notifications11:53
isviridovajaya : yeap11:53
ajayaisviridov, I will update the spec. I think for now we will be catching table creation and deletion notifications in ceilometer.11:55
isviridovYes.11:55
ajayaisviridov, Also number of indices could be inferred from the schema.11:56
isviridovajaya : you are right, we can publish it to notification message as well11:57
ajayaisviridov, The schema is being published right now in notifications.11:57
isviridovTechnically it doesn't affec anything for now, but it is important as API itself11:57
isviridovajaya : great catch!11:58
* isviridov have not looked at this part for a long time11:58
ajayahttp://paste.openstack.org/show/126446/11:59
ajayaHere is sample of notification emitted while creating a table.12:00
isviridov10x12:01
isviridovBTW we have UUID for each table, internally now https://review.openstack.org/#/c/125445/12:01
ajayaisviridov, I saw that. Great.12:02
isviridovLooking forward to seeing your spec update to join the discussion12:05
*** isviridov changes topic to "MagnetoDB - key-value store for OpenStack (https://wiki.openstack.org/wiki/MagnetoDB, logs @ https://botbot.me/freenode/magnetodb/) | Our Kilo OpenStack summit design session http://goo.gl/czt5mL| ask isviridov is any Qs"12:07
ajayaisviridov, The design session link is broken. ;)12:10
*** isviridov changes topic to "MagnetoDB - key-value store for OpenStack (https://wiki.openstack.org/wiki/MagnetoDB, logs @ https://botbot.me/freenode/magnetodb/) | Our Kilo OpenStack summit design session http://goo.gl/czt5mL | ask isviridov is any Qs"12:10
isviridovThx. Just one space missed12:10
isviridovajaya : BTW welcome to resiter and like, tweet :)12:11
*** isviridov is now known as isviridov_away12:32
*** vivekd has quit IRC13:07
*** charlesw has joined #magnetodb13:21
openstackgerritIgor Degtiarov proposed a change to stackforge/magnetodb-specs: Migration to pecan  https://review.openstack.org/13176413:25
*** jeromatron has joined #magnetodb13:34
*** rushiagr is now known as rushiagr_away13:47
*** jeromatron has quit IRC13:52
*** jeromatron has joined #magnetodb14:07
openstackgerritIgor Degtiarov proposed a change to stackforge/magnetodb-specs: Migration to pecan  https://review.openstack.org/13176414:08
isviridov_away!m idegtiarov14:25
[o__o]You're doing good work, idegtiarov!14:25
openstackisviridov_away: Error: "m" is not a valid command.14:25
*** ikhudoshyn has left #magnetodb14:29
openstackgerritIgor Degtiarov proposed a change to stackforge/magnetodb-specs: Migration to pecan  https://review.openstack.org/13176414:37
*** jeromatron has quit IRC14:45
*** jeromatron has joined #magnetodb15:01
*** rushiagr_away is now known as rushiagr15:08
*** ikhudoshyn has joined #magnetodb15:13
ikhudoshynhttps://review.openstack.org/#/c/131384/ guys pls review15:14
*** miqui has joined #magnetodb15:17
isviridov_awayikhudoshyn : will do15:20
*** isviridov_away is now known as isviridov15:20
isviridovHello miqui, how are you today?15:21
openstackgerritIgor Degtiarov proposed a change to stackforge/magnetodb-specs: Migration to pecan  https://review.openstack.org/13176415:30
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Forbid multiple operations with an item in batch write  https://review.openstack.org/13138415:38
*** keith_newstadt has joined #magnetodb15:41
*** ajaya has quit IRC15:49
*** keith_newstadt has quit IRC15:49
openstackgerritDmitriy Ukhlov proposed a change to stackforge/magnetodb: Add Forbidden exception  https://review.openstack.org/13180715:53
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Forbid multiple operations with an item in batch write  https://review.openstack.org/13138415:54
*** k4n0 has quit IRC16:03
openstackgerritNuno Santos proposed a change to stackforge/magnetodb: Record and retrieve table creation timestamp  https://review.openstack.org/13154616:25
*** keith_newstadt has joined #magnetodb16:53
*** jeromatron has quit IRC16:56
openstackgerritIllia Khudoshyn proposed a change to stackforge/magnetodb: Forbid multiple operations with an item in batch write  https://review.openstack.org/13138416:57
openstackgerritAndrei V. Ostapenko proposed a change to stackforge/magnetodb: Moves passing tempest tests to stable directory  https://review.openstack.org/13146417:13
*** jeromatron has joined #magnetodb17:16
*** denis_makogon has joined #magnetodb17:28
*** jeromatron has quit IRC17:29
*** jeromatron has joined #magnetodb17:30
*** jeromatron has quit IRC17:32
isviridovominakov : do you have ability to set bug status as triaged now?17:38
ominakovisviridov, nope17:40
isviridovominakov : please try now17:40
*** jeromatron has joined #magnetodb17:41
ominakovisviridov, yes, all set17:42
*** denis_makogon has left #magnetodb17:42
isviridovominakov : welcome to bug supervisor group17:43
*** jeromatron has quit IRC17:43
isviridovominakov : you know, I've also set tags ux and data-api to each bug you have mentioned17:43
isviridovominakov : what about this one https://bugs.launchpad.net/magnetodb/+bug/1347722 ?17:44
isviridovIs it actual?17:44
*** jeromatron has joined #magnetodb17:45
ominakovisviridov, i'll check it17:46
*** jeromatron has quit IRC17:47
isviridovominakov : got you. Thanks for info17:47
*** keith_newstadt has quit IRC17:50
*** keith_newstadt has joined #magnetodb17:50
*** isviridov is now known as isviridov_away17:51
*** miqui has quit IRC17:56
*** keith_newstadt has quit IRC18:02
*** jeromatron has joined #magnetodb18:07
*** romainh has quit IRC18:09
*** ajayaa has quit IRC19:07
*** rushiagr is now known as rushiagr_away19:10
openstackgerritNuno Santos proposed a change to stackforge/magnetodb: Document errors and exceptions for REST API  https://review.openstack.org/13185719:14
*** jeromatron has quit IRC19:19
*** jeromatron has joined #magnetodb19:32
*** jeromatron has quit IRC19:35
*** romainh has joined #magnetodb19:59
*** jeromatron has joined #magnetodb20:22
-openstackstatus- NOTICE: Restarting gerrit to get fixed CI javascript20:56
*** openstackgerrit has quit IRC21:50
*** charlesw has quit IRC22:15
*** romainh has left #magnetodb23:08
*** jeromatron has quit IRC23:59

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