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