13:00:02 #startmeeting magnetodb 13:00:03 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:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:06 The meeting name has been set to 'magnetodb' 13:00:22 Hello everybody 13:00:29 o/ 13:00:40 Who is today with us? 13:00:49 o/ 13:00:54 o/ 13:01:06 +1 13:01:13 Welcome on board idegtiarov! 13:01:24 thanks a lot 13:01:31 So the current agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda 13:02:17 Let us start from action items from last meeting 13:03:05 hi all 13:03:19 achudnovets provide numbers about performance impact from big PKI token in ML 13:03:37 hi 13:03:40 it's done 13:03:48 Hi 13:04:06 #topic Go through action items 13:04:11 achudnovets, aostapenko welcome 13:04:23 So, I think we have finished with this BP 13:04:34 [openstack-dev][MagnetoDB] PKI tokens size performance impact in mailing list 13:04:45 I mean we won't add any additional session layer 13:04:46 isviridov: I think so 13:05:02 dukhlov, ikhudoshyn agree? 13:05:07 +1 13:05:13 +1 13:05:41 Great! 13:06:00 aostapenko, your AI is next "write a spec about healthcheck" 13:06:14 I've seen it. You know my suggestions 13:07:08 aostapenko, anything to add? 13:07:13 isviridov, here it is: https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-health-check 13:07:45 aostapenko, please add the link to BP as well #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check 13:08:18 I will do some changes there and let you know 13:09:03 isviridov, ok 13:09:13 dukhlov, ikhudoshyn please take a look at it I hope we will implement is during juno 13:09:22 sure 13:09:27 dukhlov, ikhudoshyn but the spec is still not approved 13:09:50 yep, i got some questions regarding it 13:09:54 #action dukhlov ikhudoshyn review spec for https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check 13:10:04 ikhudoshyn, here? 13:10:10 why not.. 13:10:34 as spec states we are to exec some query to underlying C* 13:10:53 how this will help us to verify keystone operability? 13:11:28 if we are to allow this check w/o any credentials 13:11:42 I believe it is Q to aostapenko 13:11:52 aostapenko, have you thought about that? 13:12:27 aostapenko, if not, we could just take it offline 13:12:38 and get back later to it 13:12:54 ikhudoshyn, our goal is to check its availability 13:13:18 exactly, that's what i'm asking about 13:13:25 * isviridov has found the checking keystone in spec 13:14:17 ikhudoshyn, has fount it as well 13:14:25 s/fount/found 13:14:48 simple GET / seem not to be enough 13:15:34 so this check is an easy way to find out if magnetodb has connectivity to keystone and cassandra 13:15:50 ikhudoshyn, +1 it maybe wrong keystone 13:15:52 _connectivity_.. got it 13:16:06 or not keystone at all 13:16:22 * isviridov )))))) 13:16:31 Everything is possible 13:17:05 But let us remember that it is basic healthcheck - fast and frequently called 13:17:18 For other cases the tempest exists 13:17:39 in production especially )) 13:17:39 ikhudoshyn, ominakov next topic? 13:17:47 agree lets move on 13:17:59 yep 13:18:04 Next AI 13:18:05 ikhudoshyn write a spec for migration to oslo.messaging.notify 13:18:27 my bad, no updates here 13:18:43 np, looking forward 13:18:52 The next is my 13:18:53 isviridov look how to created magentodb-spec repo 13:19:33 Actually no upates about AI, but let me share my view and plans 13:20:22 It seems that formal spec review process would be very useful to track the statuses 13:20:58 Till we start using it, I'm marking all patches connected to not approved BP and specs and (DRAFT) 13:21:30 So, it is clear what should be reviews first 13:21:43 Any thoughts, questions here? 13:21:47 hmm /me thought we use launchpad to track statuses 13:21:56 am i wrong? 13:22:29 what's wrong with specs binded to BPs? 13:22:32 ikhudoshyn, your are right 13:22:54 There is no way to comment every line, like we have it in gerrit 13:23:04 ic 13:23:51 Another usefull thing it can be released and versioned according to project milestones. We don't have it in wiki 13:24:00 ikhudoshyn, next topic? 13:24:13 just a sec 13:24:19 Sure 13:24:45 could u at least hint us, mdb spec repo, what it is (should be)? 13:24:57 just a repo on github? 13:25:05 with gerrit process? 13:25:13 I got to go to an interview, will miss this meeting 13:25:28 Both, as any other project 13:25:29 sure charlesw 13:25:38 charlesw, hello see you after meeting 13:25:44 isviridov, that makes sense 13:25:45 #link https://github.com/openstack/nova-specs 13:25:56 #link https://review.openstack.org/#/q/status:open+openstack/nova-specs,n,z 13:26:12 #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:20 ikhudoshyn, some examples 13:26:49 Next topic 13:26:51 ajayaa write spec for RBAC 13:27:04 I could say on behalh 13:27:42 So, we have a spec #link https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac 13:28:06 ajayaa expects to finish it during juno 13:28:23 dukhlov, ikhudoshyn let us look at it i spare time 13:28:28 ajayaa seem to be not with us today 13:28:49 Yeap, it is big hilydays in India 13:28:56 I did, wrote some thoughts to ajayaa 13:28:56 * holydays 13:29:06 ikhudoshyn, great! 13:29:28 #action ikhudoshyn dukhlov review https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac 13:29:39 apart from some formal things it looks great 13:29:59 #action isviridov start create spec repo like https://github.com/openstack/nova-specs 13:30:11 I think we are ready to move forward 13:30:24 agree 13:30:28 #topic Support and enforce user roles defined in Keystone 13:30:33 #link https://blueprints.launchpad.net/magnetodb/+spec/support-roles 13:30:40 I think we have discussed it 13:30:48 Next one? 13:30:52 yes 13:31:31 It if the same as RBAC 13:31:39 #topic Monitoring - healthcheck http request 13:31:47 #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check 13:31:58 Anything to add here? 13:32:06 aostapenko, ikhudoshyn next topic? 13:32:23 ok 13:32:32 ok 13:32:34 #topic Monitoring API 13:32:46 #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-api 13:33:12 ominakov, around? 13:33:20 finally :) I have couple questions about this one 13:33:32 yes, i've faced some issues with implementation 13:33:42 Let us start with questions 13:33:54 achudnovets, please 13:34:14 are we going to use keystone for /monitoring ? 13:34:34 achudnovets, what do you mean? 13:34:51 * isviridov has initiated the BP, so also interested in questions 13:35:40 If I'm writing custom software using monitoring API should I get keystone token for my requests? 13:36:00 And what credentials I should use? 13:36:19 the same as for /data/ API? 13:36:28 A change was merged to stackforge/magnetodb: Stop using intersphinx https://review.openstack.org/123962 13:36:36 achudnovets, now you should use the same creeds for the data API 13:36:42 I see. It is good question. 13:36:47 hm.. we're to have RBAC soon, so it looks logical to have aproppriate role for that 13:36:58 I believe that we should pass authentification 13:37:11 dukhlov: I disagree 13:37:12 dukhlov, pass == omit? 13:37:23 if so I disagree as well 13:37:26 * isviridov ikhudoshyn has stolen words from my mouth 13:37:53 pass=use 13:38:15 wow :) 13:38:17 the health of the service is sensitive information, so i agree that it needs to be protected 13:38:17 dukhlov, +1 13:38:27 keith_newstadt, +1 13:38:58 monitoring role in keystone and RBAC? 13:39:13 isviridov, agree 13:39:26 agreed 13:39:41 and I'm thinking that monitoring api user may need access to some data api's, list_tables for example 13:39:43 achudnovets, does it helps? 13:39:50 yep 13:40:12 achudnovets, actually I thought the idea is to separate the two 13:40:37 and to have in monitoring API everything needed 13:40:50 ikhudoshyn, +1 13:41:00 ikhudoshyn: so we are going to move list_tables to monitoring? 13:41:09 not move, just add) 13:41:10 ominakov, it there any API description? 13:41:36 https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api 13:41:58 ikhudoshyn, thank you 13:42:03 achudnovets, we already have it in spec 13:42:10 achudnovets, here it is /{tenant_id}/monitoring/tables 13:42:42 wow, I see. Thanks, I missed this one ) 13:43:10 ok, but we have a few issues with implementation on backend side 13:43:22 ominakov, could you please describe in spec the security aspect? 13:43:58 isviridov, ok, sure 13:44:02 #action ominakov describe security impact here https://wiki.openstack.org/wiki/MagnetoDB/specs/monitoring-api 13:44:12 ominakov, what is the issue? 13:45:18 first: if we have many rows with equals hashkey and different rangekey, function estimatedKeys() return wrong number 13:45:53 ominakov, sounds too technical for the first read.. 13:45:53 for example: if we have 100000 rows it returns only 128 13:46:14 sry if I missed smth 13:46:28 ominakov, yeap I believe it is difficult to dive into context in 2 mins 13:46:39 it seems that estimatedKeys() returns cassandra wide rows count 13:46:53 not CQL rows count 13:47:10 * isviridov is looking at dukhlov and ominakov 13:47:29 * ikhudoshyn is looking at isviridov 13:47:29 ikhudoshyn, ok, we can't get number of keys by JMX if we have many rows with equal hashkey 13:47:42 so we could only get count of HASH key used 13:47:44 * isviridov hmmm 13:47:51 ominakov, thanks, this is much more readable 13:48:15 it sounds like C* has not the feature we need out of the box 13:48:34 exactly 13:48:46 yep 13:48:47 r we to implement it ourselves? 13:48:55 * isviridov sees understanding of the problem 13:50:00 now I see only one solution - create addition table for each our tables and store there keys 13:50:12 * isviridov have a next topic to discuss on the tips of his fingers 13:50:28 combine HASH and RANGE key here into HASH key 13:50:30 isviridov, agree, lets take it offline 13:50:47 dukhlov, does it mean write twice? 13:50:53 yes 13:51:07 but only keys for second table 13:51:11 isviridov, seems so. and even more, we should do that atomically 13:51:24 dukhlov, wouldn't C* count type be faster and easier? 13:51:41 we need to have set of keys 13:52:10 using counter we can calculate count of put operation for example 13:52:11 isviridov, if u mean C* atomic counters, this seem unreliable 13:52:38 but ew can execute billion put requests to put only single key 13:52:57 dukhlov, exactly 13:52:58 dukhlov, got you 13:53:28 in fact we could distinct such situations 13:53:42 but this is definitely an error-prone way 13:54:37 dukhlov, ikhudoshyn, ominakov it seeems we don't have an agreement here. Let us move on 13:54:52 +1 13:55:00 +1 13:55:00 And return back to it after the meeting 13:55:32 #topic Migrate MagnegoDB API to pecan lib 13:55:40 #link https://blueprints.launchpad.net/magnetodb/+spec/migration-to-pecan 13:55:48 Looks like smth new for me 13:55:59 idegtiarov, ? 13:56:34 idegtiarov, around? 13:56:35 sounds like 'you shall not pass' 13:56:39 )) 13:56:42 yes, probably description is not correct enough 13:56:59 I will improve it 13:57:00 idegtiarov, it's ok, just a lil'bit funny 13:57:36 idegtiarov, actually sounds good 13:57:54 I think it is great idea. We don't have any problems with it, but we have to do it eventually 13:58:08 idegtiarov, what are your plans for this? 13:58:15 I can take this task if you are not hurry with it 13:58:27 shell I prepare a spec? 13:58:28 feel fre)) 13:58:34 * free 13:58:35 idegtiarov, we are not :) 13:58:51 ikhudoshyn, idegtiarov +1 13:58:55 isviridov: ok ) 13:59:12 Waiting for your spec if so 13:59:24 isviridov: I am on my way 13:59:28 idegtiarov, ikhudoshyn next topic? 13:59:40 yes, lets go on 13:59:47 #topic Open discussion 13:59:53 Yahooo! 13:59:57 Take your time 14:00:13 Oops. We are out of timme 14:00:21 Thank you for participation 14:00:28 #endmeeting