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