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