13:00:24 <isviridov> #startmeeting magnetodb
13:00:24 <openstack> Meeting started Thu Sep 25 13:00:24 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:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:00:27 <openstack> The meeting name has been set to 'magnetodb'
13:00:32 <isviridov> o/
13:00:55 <isviridov> Anybody here?
13:01:00 <ajayaa> o/
13:01:12 <ajayaa> Hi isviridov.
13:01:28 <isviridov> Hello ajayaa
13:01:45 <aostapenko> Hi, guys
13:01:46 <ikhudoshyn> o/
13:02:11 <isviridov> #link from last meeting http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-09-18-13.01.html
13:02:28 <isviridov> Today agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Sep25.2C_2014.2C_13:00_UTC
13:02:35 <isviridov> #topic Go through action items
13:02:51 <isviridov> ikhudoshyn write spec
13:03:09 <ikhudoshyn> done
13:03:19 <isviridov> I've seen that it exists :)
13:03:21 <ikhudoshyn> just a sec, i'll find the link
13:03:38 <ikhudoshyn> https://wiki.openstack.org/wiki/MagnetoDB/specs/async-schema-operations
13:04:12 <ajayaa> Please link it to the blueprint.
13:04:13 * isviridov going through spec quickly
13:04:48 <ikhudoshyn> ajayaa, it is already linked
13:05:11 <isviridov> ikhudoshyn, looks serios
13:05:48 <isviridov> I like it. Any questions?
13:05:54 <ikhudoshyn> did my best
13:06:35 <isviridov> Ok, looking forward for your patch
13:06:50 <isviridov> Another AI is:
13:06:56 <ikhudoshyn> it's green in gerrit
13:07:00 <ajayaa> Looks nice. I will have some questions after reading through it.
13:07:06 <ikhudoshyn> everybody are welcome to review
13:07:23 <ikhudoshyn> https://review.openstack.org/#/c/122404/
13:07:29 <isviridov> Great!
13:07:41 <isviridov> achudnovets provide numbers about performance impact from big PKI token in ML
13:07:45 <isviridov> achudnovets, around?
13:07:55 <achudnovets> yes
13:08:30 <achudnovets> Hmm, I'll send an email today. With numbers.
13:08:54 <isviridov> achudnovets, cool!
13:09:01 <isviridov> #action provide numbers about performance impact from big PKI token in ML
13:09:25 <isviridov> #topic Asynchronous table creation and removal
13:09:54 <isviridov> Seems we have spec and patch to review.
13:10:02 <isviridov> ikhudoshyn, anything else to add?
13:10:08 <achudnovets> for lightweight requests, like list_tables, we can get 5% - 8% performance boost using tokens without service catalog
13:11:15 <ikhudoshyn> isviridov, nothing from my side
13:11:23 <charlesw> Hi ikhudoshyn, if you can add a section about the pros/cons of alternative approaches, it will be even better :)
13:11:42 <isviridov> Welcome charlesw
13:11:51 <ikhudoshyn> charlesw, sounds good. I'll do it.. eventually
13:12:04 <ikhudoshyn> ,)
13:12:07 <isviridov> achudnovets, I see, let us return back to it later or in ML
13:12:51 <isviridov> charlesw, what  alternatives do you mean?
13:14:34 * isviridov thinks that we have lost charlesw
13:14:38 <charlesw> I put some comments in the patch review. I think what we need there is a distributed lock. Some alternative approach can be, for example, using Cassandra itself as a global lock.
13:14:38 <isviridov> Move on?
13:14:57 <rushiagr> Hi all! Sorry, I am late..
13:15:05 <isviridov> rushiagr, welcome
13:15:38 <rushiagr> isviridov: thanks
13:15:41 <isviridov> charlesw, I see
13:15:52 <isviridov> Next topic?
13:16:26 <isviridov> #topic Monitoring API
13:16:47 <isviridov> ominakov, will you update us with latest status?
13:17:00 <ominakov> yes, sure
13:18:23 <ominakov> i've pushed new patch set with implemented size of table in bytes and item counts
13:18:28 <isviridov> #link https://blueprints.launchpad.net/magnetodb/+spec/monitoring-api
13:18:50 <isviridov> ominakov, great!
13:18:57 <ominakov> welcome to review #link https://review.openstack.org/#/c/122330/4
13:19:31 <isviridov> ominakov, I believe we have to update the deployment as well
13:20:43 <ominakov> yep, we should add Jolokia to our C* deployment
13:21:12 <ajayaa> A bit off-topic but we are starting ceiliometer integration work. So currently we have plans to catch notifications and process them in ceilometer.
13:21:55 <ajayaa> Do we plan to consume monitoring-api from ceilometer?
13:22:08 <isviridov> ajayaa, are you working on this part?
13:22:55 <isviridov> ajayaa, yes, it can be done by celio. But it is not in prior for now.
13:23:07 <ajayaa> isviridov, Yes. I have started working on ceilometer integration.
13:23:38 <isviridov> ajayaa, great to know! Let us discuss it in details out of this topic.
13:23:46 <isviridov> Moving on?
13:24:21 <ikhudoshyn> isviridov, yep
13:24:22 <ajayaa> isviridov, okay.
13:24:22 <rushiagr> isviridov: ceilometer work is important to us :)
13:24:42 <isviridov> rushiagr, I see :)
13:24:48 <isviridov> #topic Light weight session for authorization
13:25:07 <isviridov> achudnovets, do you have a conclusion about this BP?
13:26:10 <achudnovets> I think we can just use PKI tokens without service catalog
13:26:47 <isviridov> I like the approach 'to leave all as is' :)
13:26:48 <achudnovets> I'm not sure we need to provide some custom mechanism right now
13:26:56 <ikhudoshyn> achudnovets, did you do any measurements?
13:27:27 <charlesw> where is the BP?
13:27:39 <isviridov> charlesw, #link https://blueprints.launchpad.net/magnetodb/+spec/light-weight-session
13:27:58 <romainh> hi guys, just a notice. Would it possible to have longer commit messages? It would allow easier understanding of code changes :)
13:28:04 * rushiagr looks around to see if any Symantec folks are present
13:28:14 <rushiagr> romainh: +1000
13:28:14 <achudnovets> ikhudoshyn: yep, and I'll send an email with some conlusions
13:28:24 <isviridov> romainh, +2
13:28:32 <ikhudoshyn> achudnovets, yep, sry I missed yu answer before
13:28:49 <rushiagr> romainh: completely agree with you. Also, I see some commits without any blueprints, or bugs included in them..
13:28:53 <ikhudoshyn> romainh, u r right, all of us should work on it))
13:28:58 <isviridov> romainh, rushiagr feel free to -1
13:29:24 <ajayaa> achudnovets, How did you measure performance hit with PKI tokens?
13:29:35 <ajayaa> Did you use size of PKI token?
13:30:33 <charlesw> Maybe we should say authN instead of authZ?
13:31:26 <achudnovets> ajayaa: I sent a lot of requests with PIK token with enabled service catalog and without service catalog. And measure responce time and rps
13:32:19 <isviridov> charlesw, not sure. authentication is done by keystone
13:32:37 <ajayaa> achudnovets, We all agree that PKI tokens without service catalogs are nice and less in size.
13:33:23 <ikhudoshyn> move on?
13:33:27 <isviridov> achudnovets, ajayaa moving on?
13:33:37 <achudnovets> +1
13:33:49 <ajayaa> But can't we use UUID token and subtract the keystone request time from it to measure real performance impact of PKI?
13:33:49 <isviridov> #topic Review tempest tests and move to stable test dir
13:34:36 <isviridov> achudnovets, will you answer or next topic?
13:34:56 <ajayaa> we can take it offline.
13:35:08 <isviridov> Ok
13:35:09 <isviridov> #link https://blueprints.launchpad.net/magnetodb/+spec/review-tempest-tests
13:35:13 <aostapenko> I've started to review in_progress tempest tests and move some of them to stable dir, so they will affect dvsm job results
13:35:53 <isviridov> aostapenko, good job! QA is really important
13:36:08 <aostapenko> isviridov: thanks
13:36:23 <isviridov> The next one?
13:36:28 <charlesw> I noticed updateItem is missing from tempest, any reason?
13:37:20 <ikhudoshyn> charlesw, nothing but the lack of resources))
13:37:29 <ikhudoshyn> fell free to join
13:37:40 <charlesw> sure
13:37:59 <isviridov> charlesw, could you please track it as a bug?
13:38:02 <aostapenko> charlesw, could you register a blueprint
13:38:04 <ikhudoshyn> there are several areas that are not covered yet
13:38:06 <charlesw> will do
13:38:14 <rushiagr> charlesw: ikhudoshyn: I think it is high time we should start filing bugs , or writing blueprints for that matter, for such things
13:38:31 <isviridov> aostapenko, not sure that BP is need for this. But we can add work item to current one.
13:38:54 <ikhudoshyn> rushiagr, definitely. They are not bugs, I think. BPs are good for that
13:39:23 <charlesw> rushiagr, good point
13:39:26 <isviridov> charlesw, great!
13:39:35 <ikhudoshyn> ikhudoshyn, do u want one huge pending BP?
13:39:47 <rushiagr> ikhudoshyn: I'm fine with either way, but we should not let someone 'discover' these things out..
13:39:57 <ikhudoshyn> s/ikhudoshyn/isvyrydov/
13:40:35 <isviridov> rushiagr, ikhudoshyn can't say right now. Bug sounds easier to track. BP is more topic for discussion or long term effort.
13:40:36 <ikhudoshyn> rushiagr, sry , I sort of missed ur point
13:40:57 <isviridov> Let us file it as a bug and move on
13:41:16 <isviridov> #topic Monitoring - healthcheck http request
13:41:17 <rushiagr> if tempest test is missing, it should be given due importance IMO, whether bug or blueprint
13:41:18 <ikhudoshyn> ok, let them be bugs
13:41:24 <isviridov> aostapenko, it is you again
13:41:42 <rushiagr> personally it is a bug, but blueprints will do too if somoene feels like it :)
13:42:02 <isviridov> #agreed file missed tests as bugs
13:42:23 <aostapenko> Now we are looking for lightweight tool to check magnetodb health
13:42:45 <aostapenko> here is a bp https://blueprints.launchpad.net/magnetodb/+spec/monitoring-health-check
13:44:05 <aostapenko> I suppose it should be http request to magnetodb that will initiate checking of keystone and cassandra availability
13:44:10 <isviridov> aostapenko, i like it. Could you please write short spec with path, request, response
13:44:20 <aostapenko> yes. sure
13:44:38 <isviridov> dukhlov ikhudoshyn charlesw are you ok with idea?
13:45:13 <ikhudoshyn> isviridov, LGTM
13:45:24 <charlesw> sounds good
13:45:46 <isviridov> aostapenko, please go ahead with it
13:46:00 <isviridov> #action aostapenko write a spec about healthcheck
13:46:16 <isviridov> #topic Log management
13:46:17 <ajayaa> sounds good to me, but this should not be exposed to public.
13:46:23 <isviridov> #link https://blueprints.launchpad.net/magnetodb/+spec/log-rotating
13:46:36 <isviridov> I've heard about it from achuprin
13:47:35 <ikhudoshyn> isviridov, ' move out whole logging configuration file' in the spec, do you mean 'to have a separate conf file for the logging subsystem'?
13:48:04 <isviridov> Yeap, it is one of ideas. But let me first describe the problem
13:48:10 <charlesw> ajayaa, I think a ping like service can be exposed, or make it optional at deployment
13:48:18 <ikhudoshyn> isviridov, sure go ahead
13:48:53 <isviridov> We have too much logs on disk and usage of standard log rotate is not always helpful
13:49:34 <isviridov> I mean we can wrote several Gbs of logs before cron start and rotate the file
13:49:35 <rushiagr> charlesw: can you expand on the idea?
13:50:10 <aostapenko> Now we are looking for ability to use log rotating by python logging lib, or make proper config for logrotate tool
13:50:35 <isviridov> So, suggested approach is have log rotation by size on application level
13:50:58 <charlesw> let's follow meeting agenda and discuss a little later maybe.
13:51:00 <ikhudoshyn> my 2cents, having just one conf for all mdb executables does not sound like a good idea for me
13:51:16 <isviridov> charlesw, thx
13:52:22 <ikhudoshyn> do we have any numbers on the topic? Could disabling 'debug' msgs help us in any way?
13:52:24 <isviridov> ikhudoshyn, I thought about it, because rotating in standard functionality and probably it is not needed to duplicate the configuration in mdb config, but keep the standard format for logging framework
13:52:57 <isviridov> ikhudoshyn, on big deployment doesn
13:53:17 <isviridov> t help. The audit messages could fill all disk :)
13:53:21 <ikhudoshyn> isviridov, in fact we have 3 (for now) possibly separate deployables, I'd really prefer them to have their own CONFs
13:53:39 <isviridov> ikhudoshyn, agree
13:53:50 <charlesw> I'm with ikhudoshyn
13:54:21 <ikhudoshyn> so even if we gonna have a couple more conf params, lets just have them in service's personal CONFs
13:54:35 <isviridov> #agreed put log rotation configs in mdb config. No separate logging config
13:54:54 <isviridov> aostapenko, anything to add from your side?
13:55:41 <aostapenko> isviridov no. i've done
13:56:05 <isviridov> #topic Open discussion
13:56:54 <ikhudoshyn> i'd like to announce one more thing I gonna do
13:57:04 <isviridov> ikhudoshyn, please
13:57:22 <ikhudoshyn> most of OS projects already moved to oslo.messaging.notify
13:57:44 <ikhudoshyn> I plan to do the same for MDB once I finish with current activities
13:58:04 <isviridov> ikhudoshyn, is it released already?
13:59:18 <ikhudoshyn> yes, afaik
13:59:35 <isviridov> ikhudoshyn, as far as I remember it was not, that is why we have just grabbed some code.
13:59:43 <ikhudoshyn> anyway, nova, sfift, keystone ant lots more use it
14:00:06 <ikhudoshyn> isviridov, that was at the time when we implemented it in MDB
14:00:09 <isviridov> Nice to know, ikhudoshyn please file a bp for that forst
14:00:13 <ikhudoshyn> https://blueprints.launchpad.net/magnetodb/+spec/oslo-notify
14:00:30 <isviridov> WOW
14:00:41 <isviridov> Ok, spec is needed
14:01:04 <isviridov> #action ikhudoshyn write a spec for migration to  oslo.messaging.notify
14:01:06 <ajayaa> I have a working implementation of RBAC in magnetodb. I will push it once I am done with unit tests.
14:01:20 <isviridov> ajayaa, WOW!
14:01:20 <rushiagr> isviridov: do you think it is a good time to move to using magnetodb-specs as a place for tracking blueprints?
14:01:34 <charlesw> yes we should move to oslo messaging. Hopefully MDb code will be minimally impacted if any
14:01:51 <isviridov> rushiagr, yes. I agree
14:01:59 <ikhudoshyn> ajayaa, is there any spec for that?
14:02:12 <isviridov> #action isviridov look how to created magentodb-spec repo
14:02:21 <rushiagr> isviridov: let's follow it starting from Kilo
14:02:35 <isviridov> rushiagr, +1
14:02:54 <ajayaa> There is a blueprint. I am yet to write a spec. https://blueprints.launchpad.net/magnetodb/+spec/enforce-acls
14:03:04 <ajayaa> ikhudoshyn ^^
14:03:13 <ikhudoshyn> ajayaa, cool
14:03:20 <isviridov> ajayaa, cool!
14:03:27 <rushiagr> isviridov: a spec repo will be very useful for asking questions on the spec, and also make sure that specs are written comprehensively before any spec is targetted
14:03:43 <isviridov> #action ajayaa write spec for RBAC
14:04:29 <rushiagr> another suggestion: we can discuss more about 'ideas' here in the meeting, rather than discuss about status updates of blueprints
14:04:31 <isviridov> rushiagr, agree
14:05:04 <rushiagr> I find that we are spending a lot of time tracking updates only, which leaves us with very less time to debate on important ideas/discussions
14:05:15 <isviridov> rushiagr, just add an items to meeting agenda and we will discuss it
14:05:54 <rushiagr> it is partly my fault too. I should have added to agenda, the items I had to discuss :)
14:06:12 <isviridov> Ok, guys we are out of time.
14:06:14 <charlesw> also please announce meeting agenda some time before meeting so we can look into issues to be discussed
14:06:27 <isviridov> charlesw, got you
14:06:32 <rushiagr> is anyone from Symantec present here?
14:06:40 <charlesw> me
14:06:53 <rushiagr> charlesw: I wanted to discuss about cassandra provisioning
14:06:56 <isviridov> The official part of meeting is finished
14:07:00 <isviridov> #endmeeting