| *** charlesw has joined #magnetodb | 01:10 | |
| *** vnaboychenko has quit IRC | 01:30 | |
| *** vnaboychenko has joined #magnetodb | 01:58 | |
| *** vnaboychenko has quit IRC | 02:35 | |
| *** charlesw has quit IRC | 02:55 | |
| *** jeromatron has joined #magnetodb | 02:55 | |
| *** openstackgerrit has quit IRC | 03:08 | |
| *** openstackgerrit has joined #magnetodb | 03:11 | |
| *** jeromatron has quit IRC | 03:14 | |
| *** openstackgerrit has quit IRC | 03:18 | |
| *** openstackgerrit has joined #magnetodb | 03:19 | |
| *** jeromatron has joined #magnetodb | 04:00 | |
| *** rushiagr_away is now known as rushiagr | 04:12 | |
| *** vnaboychenko has joined #magnetodb | 05:16 | |
| *** jeromatron has quit IRC | 05:59 | |
| *** jeromatron has joined #magnetodb | 06:13 | |
| *** jeromatron has quit IRC | 06:15 | |
| *** jeromatron has joined #magnetodb | 06:24 | |
| *** romainh has joined #magnetodb | 06:40 | |
| *** jeromatron has quit IRC | 06:41 | |
| *** vnaboychenko has quit IRC | 07:04 | |
| *** rushiagr is now known as rushiagr_away | 08:27 | |
| *** rushiagr_away is now known as rushiagr | 08:33 | |
| *** rushiagr is now known as rushiagr_away | 09:23 | |
| *** rushiagr_away is now known as rushiagr | 09:58 | |
| openstackgerrit | Dmitriy Ukhlov proposed a change to stackforge/magnetodb: API level refactoring https://review.openstack.org/125404 | 11:28 |
|---|---|---|
| *** romainh has quit IRC | 11:44 | |
| *** romainh has joined #magnetodb | 11:48 | |
| *** romainh has left #magnetodb | 11:48 | |
| *** isviridov_away is now known as isviridov | 12:08 | |
| isviridov | aostapenko, around? | 12:09 |
| *** romainh has joined #magnetodb | 12:17 | |
| aostapenko | isviridov, hi | 12:18 |
| isviridov | Concerning https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check | 12:19 |
| isviridov | Could you please update cql query as we discussed and add seection about implementation? | 12:20 |
| isviridov | I believe we have to add the same for streaming api as well. | 12:20 |
| isviridov | I mean within this BP | 12:20 |
| aostapenko | isviridov: yes, I believe so too | 12:28 |
| *** romainh has quit IRC | 12:31 | |
| *** romainh has joined #magnetodb | 12:32 | |
| openstackgerrit | Ilya Sviridov proposed a change to stackforge/magnetodb: (DRAFT)Monitoring health check request https://review.openstack.org/125108 | 12:37 |
| *** achuprin_ has joined #magnetodb | 12:52 | |
| achuprin_ | Hello everyone! | 12:52 |
| isviridov | achuprin_, hello | 12:54 |
| isviridov | aostapenko, just renamed your patch with adding (DRAFT) due to not approved BP | 12:54 |
| isviridov | Hello everyone! | 12:57 |
| isviridov | Having a meeting in mins | 12:58 |
| *** keith_newstadt has joined #magnetodb | 12:58 | |
| isviridov | I believe we can start | 12:59 |
| isviridov | #startmeeting magnetodb | 13:00 |
| openstack | Meeting started Thu Oct 2 13:00:02 2014 UTC and is due to finish in 60 minutes. The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 13:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 13:00 |
| openstack | The meeting name has been set to 'magnetodb' | 13:00 |
| isviridov | Hello everybody | 13:00 |
| idegtiarov | o/ | 13:00 |
| isviridov | Who is today with us? | 13:00 |
| achuprin_ | o/ | 13:00 |
| ikhudoshyn | o/ | 13:00 |
| dukhlov | +1 | 13:01 |
| isviridov | Welcome on board idegtiarov! | 13:01 |
| idegtiarov | thanks a lot | 13:01 |
| isviridov | So the current agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda | 13:01 |
| isviridov | Let us start from action items from last meeting | 13:02 |
| keith_newstadt | hi all | 13:03 |
| isviridov | achudnovets provide numbers about performance impact from big PKI token in ML | 13:03 |
| achudnovets | hi | 13:03 |
| achudnovets | it's done | 13:03 |
| aostapenko | Hi | 13:03 |
| isviridov | #topic Go through action items | 13:04 |
| isviridov | achudnovets, aostapenko welcome | 13:04 |
| isviridov | So, I think we have finished with this BP | 13:04 |
| achudnovets | [openstack-dev][MagnetoDB] PKI tokens size performance impact in mailing list | 13:04 |
| isviridov | I mean we won't add any additional session layer | 13:04 |
| achudnovets | isviridov: I think so | 13:04 |
| isviridov | dukhlov, ikhudoshyn agree? | 13:05 |
| ikhudoshyn | +1 | 13:05 |
| dukhlov | +1 | 13:05 |
| isviridov | Great! | 13:05 |
| isviridov | aostapenko, your AI is next "write a spec about healthcheck" | 13:06 |
| isviridov | I've seen it. You know my suggestions | 13:06 |
| isviridov | aostapenko, anything to add? | 13:07 |
| aostapenko | isviridov, here it is: https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check | 13:07 |
| isviridov | aostapenko, please add the link to BP as well #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check | 13:07 |
| aostapenko | I will do some changes there and let you know | 13:08 |
| aostapenko | isviridov, ok | 13:09 |
| isviridov | dukhlov, ikhudoshyn please take a look at it I hope we will implement is during juno | 13:09 |
| dukhlov | sure | 13:09 |
| isviridov | dukhlov, ikhudoshyn but the spec is still not approved | 13:09 |
| ikhudoshyn | yep, i got some questions regarding it | 13:09 |
| isviridov | #action dukhlov ikhudoshyn review spec for https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check | 13:09 |
| isviridov | ikhudoshyn, here? | 13:10 |
| ikhudoshyn | why not.. | 13:10 |
| ikhudoshyn | as spec states we are to exec some query to underlying C* | 13:10 |
| ikhudoshyn | how this will help us to verify keystone operability? | 13:10 |
| ikhudoshyn | if we are to allow this check w/o any credentials | 13:11 |
| isviridov | I believe it is Q to aostapenko | 13:11 |
| ikhudoshyn | aostapenko, have you thought about that? | 13:11 |
| ikhudoshyn | aostapenko, if not, we could just take it offline | 13:12 |
| ikhudoshyn | and get back later to it | 13:12 |
| aostapenko | ikhudoshyn, our goal is to check its availability | 13:12 |
| ikhudoshyn | exactly, that's what i'm asking about | 13:13 |
| * isviridov has found the checking keystone in spec | 13:13 | |
| ikhudoshyn | ikhudoshyn, has fount it as well | 13:14 |
| ikhudoshyn | s/fount/found | 13:14 |
| ikhudoshyn | simple GET / seem not to be enough | 13:14 |
| aostapenko | so this check is an easy way to find out if magnetodb has connectivity to keystone and cassandra | 13:15 |
| ominakov | ikhudoshyn, +1 it maybe wrong keystone | 13:15 |
| ikhudoshyn | _connectivity_.. got it | 13:15 |
| dukhlov | or not keystone at all | 13:16 |
| * isviridov )))))) | 13:16 | |
| isviridov | Everything is possible | 13:16 |
| isviridov | But let us remember that it is basic healthcheck - fast and frequently called | 13:17 |
| isviridov | For other cases the tempest exists | 13:17 |
| ikhudoshyn | in production especially )) | 13:17 |
| isviridov | ikhudoshyn, ominakov next topic? | 13:17 |
| ikhudoshyn | agree lets move on | 13:17 |
| ominakov | yep | 13:17 |
| isviridov | Next AI | 13:18 |
| isviridov | ikhudoshyn write a spec for migration to oslo.messaging.notify | 13:18 |
| ikhudoshyn | my bad, no updates here | 13:18 |
| isviridov | np, looking forward | 13:18 |
| isviridov | The next is my | 13:18 |
| isviridov | isviridov look how to created magentodb-spec repo | 13:18 |
| isviridov | Actually no upates about AI, but let me share my view and plans | 13:19 |
| isviridov | It seems that formal spec review process would be very useful to track the statuses | 13:20 |
| isviridov | Till we start using it, I'm marking all patches connected to not approved BP and specs and (DRAFT) | 13:20 |
| isviridov | So, it is clear what should be reviews first | 13:21 |
| isviridov | Any thoughts, questions here? | 13:21 |
| ikhudoshyn | hmm /me thought we use launchpad to track statuses | 13:21 |
| *** charlesw has joined #magnetodb | 13:21 | |
| ikhudoshyn | am i wrong? | 13:21 |
| ikhudoshyn | what's wrong with specs binded to BPs? | 13:22 |
| isviridov | ikhudoshyn, your are right | 13:22 |
| isviridov | There is no way to comment every line, like we have it in gerrit | 13:22 |
| ikhudoshyn | ic | 13:23 |
| isviridov | Another usefull thing it can be released and versioned according to project milestones. We don't have it in wiki | 13:23 |
| isviridov | ikhudoshyn, next topic? | 13:24 |
| ikhudoshyn | just a sec | 13:24 |
| isviridov | Sure | 13:24 |
| ikhudoshyn | could u at least hint us, mdb spec repo, what it is (should be)? | 13:24 |
| ikhudoshyn | just a repo on github? | 13:24 |
| ikhudoshyn | with gerrit process? | 13:25 |
| charlesw | I got to go to an interview, will miss this meeting | 13:25 |
| isviridov | Both, as any other project | 13:25 |
| ikhudoshyn | sure charlesw | 13:25 |
| isviridov | charlesw, hello see you after meeting | 13:25 |
| ikhudoshyn | isviridov, that makes sense | 13:25 |
| isviridov | #link https://github.com/openstack/nova-specs | 13:25 |
| isviridov | #link https://review.openstack.org/#/q/status:open+openstack/nova-specs,n,z | 13:25 |
| isviridov | #link http://docs-draft.openstack.org/41/125241/1/check/gate-nova-specs-docs/e966557/doc/build/html/specs/juno/add-all-in-list-operator-to-extra-spec-ops.html | 13:26 |
| isviridov | ikhudoshyn, some examples | 13:26 |
| isviridov | Next topic | 13:26 |
| isviridov | ajayaa write spec for RBAC | 13:26 |
| isviridov | I could say on behalh | 13:27 |
| isviridov | So, we have a spec #link https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac | 13:27 |
| isviridov | ajayaa expects to finish it during juno | 13:28 |
| isviridov | dukhlov, ikhudoshyn let us look at it i spare time | 13:28 |
| ikhudoshyn | ajayaa seem to be not with us today | 13:28 |
| isviridov | Yeap, it is big hilydays in India | 13:28 |
| ikhudoshyn | I did, wrote some thoughts to ajayaa | 13:28 |
| isviridov | * holydays | 13:28 |
| isviridov | ikhudoshyn, great! | 13:29 |
| isviridov | #action ikhudoshyn dukhlov review https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac | 13:29 |
| ikhudoshyn | apart from some formal things it looks great | 13:29 |
| isviridov | #action isviridov start create spec repo like https://github.com/openstack/nova-specs | 13:29 |
| *** vnaboychenko has joined #magnetodb | 13:30 | |
| isviridov | I think we are ready to move forward | 13:30 |
| ikhudoshyn | agree | 13:30 |
| isviridov | #topic Support and enforce user roles defined in Keystone | 13:30 |
| isviridov | #link https://blueprints.launchpad.net/magnetodb/+spec/support-roles | 13:30 |
| isviridov | I think we have discussed it | 13:30 |
| isviridov | Next one? | 13:30 |
| dukhlov | yes | 13:30 |
| isviridov | It if the same as RBAC | 13:31 |
| isviridov | #topic Monitoring - healthcheck http request | 13:31 |
| isviridov | #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check | 13:31 |
| isviridov | Anything to add here? | 13:31 |
| isviridov | aostapenko, ikhudoshyn next topic? | 13:32 |
| ikhudoshyn | ok | 13:32 |
| aostapenko | ok | 13:32 |
| isviridov | #topic Monitoring API | 13:32 |
| isviridov | #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-api | 13:32 |
| isviridov | ominakov, around? | 13:33 |
| achudnovets | finally :) I have couple questions about this one | 13:33 |
| ominakov | yes, i've faced some issues with implementation | 13:33 |
| isviridov | Let us start with questions | 13:33 |
| isviridov | achudnovets, please | 13:33 |
| achudnovets | are we going to use keystone for /monitoring ? | 13:34 |
| isviridov | achudnovets, what do you mean? | 13:34 |
| * isviridov has initiated the BP, so also interested in questions | 13:34 | |
| achudnovets | If I'm writing custom software using monitoring API should I get keystone token for my requests? | 13:35 |
| achudnovets | And what credentials I should use? | 13:36 |
| achudnovets | the same as for /data/ API? | 13:36 |
| openstackgerrit | A change was merged to stackforge/magnetodb: Stop using intersphinx https://review.openstack.org/123962 | 13:36 |
| ominakov | achudnovets, now you should use the same creeds for the data API | 13:36 |
| isviridov | I see. It is good question. | 13:36 |
| ikhudoshyn | hm.. we're to have RBAC soon, so it looks logical to have aproppriate role for that | 13:36 |
| dukhlov | I believe that we should pass authentification | 13:36 |
| achudnovets | dukhlov: I disagree | 13:37 |
| ikhudoshyn | dukhlov, pass == omit? | 13:37 |
| ikhudoshyn | if so I disagree as well | 13:37 |
| * isviridov ikhudoshyn has stolen words from my mouth | 13:37 | |
| dukhlov | pass=use | 13:37 |
| achudnovets | wow :) | 13:38 |
| keith_newstadt | the health of the service is sensitive information, so i agree that it needs to be protected | 13:38 |
| isviridov | dukhlov, +1 | 13:38 |
| isviridov | keith_newstadt, +1 | 13:38 |
| isviridov | monitoring role in keystone and RBAC? | 13:38 |
| ikhudoshyn | isviridov, agree | 13:39 |
| keith_newstadt | agreed | 13:39 |
| achudnovets | and I'm thinking that monitoring api user may need access to some data api's, list_tables for example | 13:39 |
| isviridov | achudnovets, does it helps? | 13:39 |
| achudnovets | yep | 13:39 |
| ikhudoshyn | achudnovets, actually I thought the idea is to separate the two | 13:40 |
| ikhudoshyn | and to have in monitoring API everything needed | 13:40 |
| ominakov | ikhudoshyn, +1 | 13:40 |
| achudnovets | ikhudoshyn: so we are going to move list_tables to monitoring? | 13:41 |
| ikhudoshyn | not move, just add) | 13:41 |
| isviridov | ominakov, it there any API description? | 13:41 |
| ikhudoshyn | https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api | 13:41 |
| isviridov | ikhudoshyn, thank you | 13:41 |
| ikhudoshyn | achudnovets, we already have it in spec | 13:42 |
| isviridov | achudnovets, here it is /{tenant_id}/monitoring/tables | 13:42 |
| achudnovets | wow, I see. Thanks, I missed this one ) | 13:42 |
| ominakov | ok, but we have a few issues with implementation on backend side | 13:43 |
| isviridov | ominakov, could you please describe in spec the security aspect? | 13:43 |
| ominakov | isviridov, ok, sure | 13:43 |
| isviridov | #action ominakov describe security impact here https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api | 13:44 |
| isviridov | ominakov, what is the issue? | 13:44 |
| ominakov | first: if we have many rows with equals hashkey and different rangekey, function estimatedKeys() return wrong number | 13:45 |
| ikhudoshyn | ominakov, sounds too technical for the first read.. | 13:45 |
| ominakov | for example: if we have 100000 rows it returns only 128 | 13:45 |
| ikhudoshyn | sry if I missed smth | 13:46 |
| isviridov | ominakov, yeap I believe it is difficult to dive into context in 2 mins | 13:46 |
| dukhlov | it seems that estimatedKeys() returns cassandra wide rows count | 13:46 |
| dukhlov | not CQL rows count | 13:46 |
| * isviridov is looking at dukhlov and ominakov | 13:47 | |
| * ikhudoshyn is looking at isviridov | 13:47 | |
| ominakov | ikhudoshyn, ok, we can't get number of keys by JMX if we have many rows with equal hashkey | 13:47 |
| dukhlov | so we could only get count of HASH key used | 13:47 |
| * isviridov hmmm | 13:47 | |
| ikhudoshyn | ominakov, thanks, this is much more readable | 13:47 |
| ikhudoshyn | it sounds like C* has not the feature we need out of the box | 13:48 |
| dukhlov | exactly | 13:48 |
| ominakov | yep | 13:48 |
| ikhudoshyn | r we to implement it ourselves? | 13:48 |
| * isviridov sees understanding of the problem | 13:48 | |
| dukhlov | now I see only one solution - create addition table for each our tables and store there keys | 13:50 |
| * isviridov have a next topic to discuss on the tips of his fingers | 13:50 | |
| dukhlov | combine HASH and RANGE key here into HASH key | 13:50 |
| ikhudoshyn | isviridov, agree, lets take it offline | 13:50 |
| isviridov | dukhlov, does it mean write twice? | 13:50 |
| dukhlov | yes | 13:50 |
| dukhlov | but only keys for second table | 13:51 |
| ikhudoshyn | isviridov, seems so. and even more, we should do that atomically | 13:51 |
| isviridov | dukhlov, wouldn't C* count type be faster and easier? | 13:51 |
| dukhlov | we need to have set of keys | 13:51 |
| dukhlov | using counter we can calculate count of put operation for example | 13:52 |
| ikhudoshyn | isviridov, if u mean C* atomic counters, this seem unreliable | 13:52 |
| dukhlov | but ew can execute billion put requests to put only single key | 13:52 |
| ikhudoshyn | dukhlov, exactly | 13:52 |
| isviridov | dukhlov, got you | 13:52 |
| ikhudoshyn | in fact we could distinct such situations | 13:53 |
| ikhudoshyn | but this is definitely an error-prone way | 13:53 |
| isviridov | dukhlov, ikhudoshyn, ominakov it seeems we don't have an agreement here. Let us move on | 13:54 |
| ikhudoshyn | +1 | 13:54 |
| ominakov | +1 | 13:55 |
| isviridov | And return back to it after the meeting | 13:55 |
| isviridov | #topic Migrate MagnegoDB API to pecan lib | 13:55 |
| isviridov | #link https://blueprints.launchpad.net/magnetodb/+spec/migration-to-pecan | 13:55 |
| isviridov | Looks like smth new for me | 13:55 |
| isviridov | idegtiarov, ? | 13:55 |
| isviridov | idegtiarov, around? | 13:56 |
| ikhudoshyn | sounds like 'you shall not pass' | 13:56 |
| ikhudoshyn | )) | 13:56 |
| idegtiarov | yes, probably description is not correct enough | 13:56 |
| idegtiarov | I will improve it | 13:56 |
| ikhudoshyn | idegtiarov, it's ok, just a lil'bit funny | 13:57 |
| ikhudoshyn | idegtiarov, actually sounds good | 13:57 |
| isviridov | I think it is great idea. We don't have any problems with it, but we have to do it eventually | 13:57 |
| isviridov | idegtiarov, what are your plans for this? | 13:58 |
| idegtiarov | I can take this task if you are not hurry with it | 13:58 |
| idegtiarov | shell I prepare a spec? | 13:58 |
| ikhudoshyn | feel fre)) | 13:58 |
| ikhudoshyn | * free | 13:58 |
| isviridov | idegtiarov, we are not :) | 13:58 |
| isviridov | ikhudoshyn, idegtiarov +1 | 13:58 |
| idegtiarov | isviridov: ok ) | 13:58 |
| isviridov | Waiting for your spec if so | 13:59 |
| idegtiarov | isviridov: I am on my way | 13:59 |
| isviridov | idegtiarov, ikhudoshyn next topic? | 13:59 |
| idegtiarov | yes, lets go on | 13:59 |
| isviridov | #topic Open discussion | 13:59 |
| isviridov | Yahooo! | 13:59 |
| isviridov | Take your time | 13:59 |
| isviridov | Oops. We are out of timme | 14:00 |
| isviridov | Thank you for participation | 14:00 |
| isviridov | #endmeeting | 14:00 |
| openstack | Meeting ended Thu Oct 2 14:00:28 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-02-13.00.html | 14:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-02-13.00.txt | 14:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-10-02-13.00.log.html | 14:00 |
| isviridov | dukhlov, ominakov, ikhudoshyn are you ready to continue about counters? | 14:01 |
| ominakov | isviridov, sure | 14:01 |
| isviridov | So, the last was error-prone | 14:02 |
| ikhudoshyn | ok i'm here | 14:03 |
| isviridov | ikhudoshyn, could you explain? | 14:03 |
| isviridov | If I understood correctly we are goung to store all keys in separate table | 14:05 |
| isviridov | For every item | 14:05 |
| isviridov | And delete it when item is deleted | 14:05 |
| ikhudoshyn | 2 mins | 14:06 |
| * isviridov will come back in 5 mins | 14:06 | |
| openstackgerrit | Andrei V. Ostapenko proposed a change to stackforge/magnetodb: (DRAFT) Monitoring health check request https://review.openstack.org/125108 | 14:07 |
| ikhudoshyn | isviridov, I mean using C* atomic counters to count items on put/update/delete is error-prone, if we go this way I think we should run separate process time to time, to check and correct these counters | 14:12 |
| ikhudoshyn | storing keys in separate table sounds much better | 14:16 |
| isviridov | ikhudoshyn, we can increment/decrement | 14:16 |
| ikhudoshyn | but still it will make our write operations much more complex | 14:16 |
| achudnovets | ikhudoshyn: and slow :( | 14:17 |
| ikhudoshyn | isviridov, thats exactly what i'd prefer not to do | 14:17 |
| ikhudoshyn | achudnovets, +1 | 14:17 |
| ikhudoshyn | so for now both proposed ways look not that great | 14:17 |
| isviridov | Not sure what is slower increment or write new key | 14:18 |
| ikhudoshyn | isviridov, increment will require much more complex logic | 14:18 |
| isviridov | cons for keys is space usage | 14:18 |
| ikhudoshyn | that's what i called error-prone | 14:18 |
| isviridov | ikhudoshyn, what logic do you mean? | 14:18 |
| ikhudoshyn | on each put u should first figure out whether u really insern NEW item. if not ur not supposed to inc counter | 14:19 |
| isviridov | ikhudoshyn, ic | 14:19 |
| ikhudoshyn | and more.. incrementing counter will still require separate write to C*, atomic with the main write | 14:20 |
| ikhudoshyn | which is slow | 14:20 |
| isviridov | ikhudoshyn, here it is the say and writing the keys | 14:21 |
| isviridov | * same | 14:21 |
| ikhudoshyn | ?? | 14:21 |
| isviridov | the same as writing the keys to additional table | 14:21 |
| isviridov | I mean require additional write and more or less atomicity | 14:22 |
| ominakov | we could just write keys to additional table | 14:22 |
| ominakov | without any check | 14:23 |
| isviridov | ominakov, ikhudoshyn agree | 14:23 |
| ikhudoshyn | ominakov, agree | 14:24 |
| isviridov | dukhlov, your vote? | 14:24 |
| romainh | hi all, you're talking about estimateKeys(), counter and so on. Is there any bp explaining the need? | 14:24 |
| isviridov | romainh, hello | 14:24 |
| ominakov | hello, romainh | 14:24 |
| ominakov | we have only general bp for monitoring-api | 14:25 |
| isviridov | romainh, yes, the thing is to count how much items do we have in table more details here #link https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api | 14:25 |
| romainh | hello guys, hope I'm not bother you | 14:25 |
| isviridov | romainh, we really need your eyes | 14:25 |
| isviridov | romainh, current problem is that our data structure is not mapped exactly to cassandra ones. So we can have different numbers of mdb items and C* keys | 14:28 |
| isviridov | Current idea is to keep the mdb items keys in separate C* table where we will have 1-1 mapping, so could use estimateKeys(), | 14:28 |
| dukhlov | I don't know how you going to implement this task using counters | 14:28 |
| romainh | estimateKeys() will estimate the number of keys in SSTable, it's fast | 14:30 |
| dukhlov | romainh: problem for now is that estimateKeys() estimates count of cassandra partition keys | 14:30 |
| ikhudoshyn | romainh, we found issues with estimateKeys() | 14:31 |
| dukhlov | in case when we are using CQL table we need the same value as well as SELECT COUNT(*) returned | 14:31 |
| ikhudoshyn | it seem to report incorrectly in some cases | 14:31 |
| ominakov | romainh, yes, and it works wrong if we have many rows with equal hash key and different range key | 14:32 |
| romainh | yes, estimateKeys() is an estimation in SSTable files based on index size, so it's a pretty raw metric | 14:33 |
| *** vnaboychenko has quit IRC | 14:34 | |
| romainh | it's not a good idea for fine grain stats | 14:34 |
| ikhudoshyn | some rough estimate might work for us, but this seem to be TOO rough | 14:35 |
| romainh | if we need accurate metrics, we will add an performance penalty inevitably | 14:36 |
| ikhudoshyn | looks like we're back to our savink-keys solution | 14:40 |
| ikhudoshyn | * saving | 14:41 |
| isviridov | ikhudoshyn, +1 | 14:42 |
| isviridov | dukhlov, charlesw ? | 14:42 |
| dukhlov | +1 | 14:43 |
| isviridov | Agreed! | 14:43 |
| isviridov | ominakov, it seems that BP scope has been extened | 14:43 |
| ominakov | ok, i'll extend BP | 14:44 |
| isviridov | ominakov, great! | 14:46 |
| openstackgerrit | Illia Khudoshyn proposed a change to stackforge/magnetodb: Add 'last_updated' to 'table_info' https://review.openstack.org/124317 | 14:51 |
| openstackgerrit | Illia Khudoshyn proposed a change to stackforge/magnetodb: Add 'last_updated' to 'table_info' https://review.openstack.org/124317 | 14:52 |
| *** vnaboychenko has joined #magnetodb | 14:53 | |
| *** isviridov is now known as isviridov_meetin | 14:57 | |
| openstackgerrit | Nuno Santos proposed a change to stackforge/magnetodb: Additional validation on index name and table name patterns https://review.openstack.org/125445 | 14:58 |
| *** jeromatron has joined #magnetodb | 15:03 | |
| *** jeromatron has quit IRC | 15:10 | |
| *** jeromatron has joined #magnetodb | 15:10 | |
| *** jeromatron has quit IRC | 15:11 | |
| romainh | ikhudoshyn: "some rough estimate might work for us" -> What accuracy ratio would do the trick? | 15:37 |
| ikhudoshyn | well, now we get response 128 when we actually have 100k items inserted)) | 15:45 |
| ikhudoshyn | mb we just use it wrong way | 15:45 |
| openstackgerrit | Illia Khudoshyn proposed a change to stackforge/magnetodb: Add 'last_updated' to 'table_info' https://review.openstack.org/124317 | 15:47 |
| romainh | ikhudoshyn: so, you have a hundred of wide rows. I will look at the items SSTable representation in CQL to get an idea | 16:21 |
| *** romainh has quit IRC | 16:47 | |
| openstackgerrit | Andrei V. Ostapenko proposed a change to stackforge/magnetodb: (DRAFT) Monitoring health check request https://review.openstack.org/125108 | 16:47 |
| *** isviridov_meetin is now known as isviridov_away | 17:05 | |
| *** jeromatron has joined #magnetodb | 17:11 | |
| *** keith_newstadt has quit IRC | 17:48 | |
| *** jeromatron has quit IRC | 18:43 | |
| *** jeromatron has joined #magnetodb | 18:49 | |
| *** rushiagr has quit IRC | 19:01 | |
| *** rushiagr has joined #magnetodb | 19:19 | |
| *** rushiagr is now known as rushiagr_away | 20:23 | |
| *** rushiagr_away is now known as rushiagr | 20:23 | |
| *** rushiagr is now known as rushiagr_away | 20:53 | |
| *** charlesw has quit IRC | 22:26 | |
| *** charlesw has joined #magnetodb | 23:02 | |
| *** vnaboychenko has quit IRC | 23:24 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!