14:00:30 <isviridov> #startmeeting magnetodb 14:00:32 <openstack> Meeting started Thu Nov 20 14:00:30 2014 UTC and is due to finish in 60 minutes. The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:35 <openstack> The meeting name has been set to 'magnetodb' 14:00:45 <isviridov> Hello everybody 14:00:57 <nunosantos> o/ 14:01:06 <isviridov> nunosantos : o/ 14:01:15 <dukhlov> _o/ 14:01:37 <achuprin_> o/ 14:01:41 <isviridov> miqui : miqui_____ welcome to mdb weekly meeting 14:01:46 <ikhudoshyn> dukhlov works as a traffic regulator 14:02:07 <dukhlov> _o_| 14:02:08 <miqui_____> hello 14:02:17 <miqui_____> sorry had some irc client uissues on my side.. 14:02:41 <isviridov> miqui_____ : have we meet each other on summit? 14:02:57 <miqui_____> i was in april 2014 atlanta summit 14:03:19 <isviridov> Today agenda #link https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda 14:03:21 <miqui_____> your nick seems familiar somehow.. 14:03:47 <isviridov> miqui_____ : welcome back if so :) 14:03:54 <miqui_____> ..thanks... 14:04:08 <isviridov> Let us start from action items 14:04:14 <isviridov> #topic Go through action items isviridov 14:04:22 <isviridov> #link http://eavesdrop.openstack.org/meetings/isviridov/2014/isviridov.2014-11-13-14.01.html 14:04:35 * isviridov dukhlov data encryption support blueprint 14:05:23 <dukhlov> hm 14:05:29 * isviridov good start 14:05:55 <dukhlov> specification for this blueprint is under review now 14:06:20 <isviridov> #link https://review.openstack.org/#/c/134936/ 14:06:27 <isviridov> #link https://review.openstack.org/#/c/133505/ 14:06:40 <dukhlov> I got -1 from isviridov, but there were only grammar mistakes 14:07:07 <dukhlov> I'm waiting for other feedback 14:07:33 <isviridov> dukhlov : I was a bit surprised that we have the general one. I mean - Specification for data-encryption-support. Do you think we need it? 14:09:12 <isviridov> charlesw : hello 14:09:24 <dukhlov> ok, for encryption support we need to have implemented at least part of management API 14:09:25 <charlesw> Hi 14:09:28 <rushiagr> o/ 14:09:34 <isviridov> hi rushiagr 14:09:43 <ajayaa> Hi everyone. 14:10:10 <isviridov> hello ajayaa 14:10:51 <dukhlov> so I added sub smaller blueprint - part of management API for encryption and set it as dependency for encryption support blueprint 14:11:05 <isviridov> charlesw : rushiagr ajayaa discussing https://review.openstack.org/#/c/134936/ 14:11:54 <isviridov> dukhlov : ok. I think we have to link them during merge 14:12:06 <isviridov> dukhlov : great job! 14:12:11 <dukhlov> as you wish 14:12:35 <isviridov> Ok, let us move to next item 14:12:36 * isviridov ikhudoshyn file a bug about dynamodb version support documentation 14:12:50 <ikhudoshyn> done 14:13:01 <ikhudoshyn> https://bugs.launchpad.net/magnetodb/+bug/1394575 14:13:32 <isviridov> ikhudoshyn : yes, I've seen. Great 14:14:10 <isviridov> Ok, we have 2 other topics to discuss 14:14:11 * isviridov keith_newstadt isviridov ikhudoshyn clarify if we can avoid having two different apis for db backup/restore inside of openstack 14:14:21 * isviridov keith_newstadt isviridov ikhudoshyn clarify if we can avoid having two different implementations of that api 14:14:45 <isviridov> Let us do it together with bp discussion 14:14:53 <ominakov> sorry guys, i'm late 14:15:04 <isviridov> #topic Discuss Backup/restore API specification draft https://review.openstack.org/#/c/133933/ ikhudoshyn 14:15:43 <ikhudoshyn> it hangs for couple weeks yet 14:15:58 <ikhudoshyn> only small amount of comments arise 14:16:15 <ikhudoshyn> i tried to address all of them 14:16:17 <isviridov> #link http://docs-draft.openstack.org/33/133933/12/check/gate-magnetodb-specs-docs/e0b7b92/doc/build/html/specs/kilo/approved/backup-restore-api.html for easier reading 14:17:13 <ajayaa> isviridov, that is helpful. 14:18:50 <charlesw> during backup/restore, shouldn't the tenant/table be locked? 14:19:14 <ikhudoshyn> we don't see any general reason 14:19:33 <ikhudoshyn> it may still be required for some implementations of backup 14:20:24 <ikhudoshyn> some of us thought about exporting data in json format as the 1st approach 14:20:44 <ikhudoshyn> we dont seem to need any loking in that case 14:20:53 <ikhudoshyn> * locking 14:22:09 <isviridov> ikhudoshyn : but, I believe, all others will need it and it affects usage scenario. Do you think that we have to describe teh locking process within this spec? 14:22:37 <ikhudoshyn> not in *that* spec since it only describes API 14:23:09 <ikhudoshyn> i'd prefer not to manage table/tenant locking manually 14:23:36 <charlesw> We should document it so we can manage user expectations whether locking is used or not 14:24:07 <ikhudoshyn> charlesw: somewhere.. 14:24:47 <charlesw> ok, preferably at API level 14:25:04 <isviridov> ikhudoshyn: as API Impact section if any is expected 14:25:58 <ikhudoshyn> as I said i'd rather not to lock it manually -- so we could just add new tables status, like MAINTENANCE 14:27:07 <ajayaa> ikhudoshyn, +1 14:27:17 <charlesw> +1 14:27:29 <isviridov> ikhudoshyn : does it mean the users requests will be rejected if table is in this status? 14:28:02 <miqui_____> ..that would de3pend of the use case.. 14:28:03 <ikhudoshyn> yep.. i thought about 403 14:28:18 <ikhudoshyn> guess there should be more suitable err code 14:28:31 <miqui_____> 1 - hey here your latest snapshot http 200 14:28:35 <miqui_____> 2 - or simply 403 14:28:57 <ikhudoshyn> not sure latest snapshot is always available 14:29:36 <isviridov> ikhudoshyn +1, also for writing as well 14:29:39 <charlesw> 503 Service Unavailable may be more appropriate 14:29:44 <miqui_____> hmm good point...if that is the case then 503 14:30:16 <ikhudoshyn> charlesw: we might think more.. 14:30:40 <ikhudoshyn> actually it is not the whole service that is unavailable.. 14:30:55 <isviridov> #idea we could just add new tables status, like MAINTENANCE 14:30:56 <ajayaa> 423 Locked 14:30:59 <ajayaa> ? 14:31:06 <ikhudoshyn> ajayaa: exactly 14:31:10 <ikhudoshyn> tnx 14:31:30 <isviridov> #idea 423 Locked on request during backup 14:31:51 <ikhudoshyn> * when in MAINTENANCE status 14:32:08 <ikhudoshyn> not necessary for every backup 14:32:21 <isviridov> ikhudoshyn : +1 14:33:00 <isviridov> ikhudoshyn : charlesw ajayaa miqui_____ move on? 14:33:17 <ajayaa> +1 14:33:32 <ikhudoshyn> agree, I'm just waiting for yr +/1's 14:33:47 <ikhudoshyn> * +/-1's 14:34:11 <isviridov> ikhudoshyn : you will have it :) 14:34:16 <isviridov> #topic Open discussion isviridov 14:34:49 <ajayaa> Code review: https://review.openstack.org/#/c/124391/ 14:34:57 <ajayaa> *needed 14:35:57 <isviridov> spec #link https://wiki.openstack.org/wiki/MagnetoDB/specs/rbac 14:36:16 <isviridov> ajayaa : great progress! 14:36:38 <isviridov> #action dukhlov charlesw ikhudoshyn isviridov review https://review.openstack.org/#/c/124391/ 14:37:23 <miqui_____> for my part... am new to the project.. 14:37:34 <isviridov> ajayaa : I just don't remember if we have finished with a spec 14:37:40 <miqui_____> so am going through the bugs and see where i can start 14:38:00 <ajayaa> isviridov, This was before we had a spec system in place. :) 14:38:11 <isviridov> miqui_____ : welcome on board! 14:38:16 <miqui_____> ...thanks!! 14:39:12 <ajayaa> But the wiki page is informative enough I guess. 14:39:14 <isviridov> miqui_____ : pay attention to https://bugs.launchpad.net/magnetodb/+bugs?field.tag=low-hanging-fruit and https://launchpad.net/magnetodb/+milestone/kilo-1 bugs 14:39:38 <miqui_____> awesome... thanks... 14:39:55 <isviridov> miqui_____ : looking for your patches. Always feel free to ask. 14:40:07 <isviridov> miqui_____ : what is your timezone? 14:40:13 <miqui_____> EST 14:40:50 <miqui_____> EST ( US east coast) 14:41:09 <isviridov> ajayaa : yeap, let me look at it. I believe we will add monitoring action at least. 14:41:16 <charlesw> @miqui, welcome, we are in same tz 14:41:24 <miqui_____> cool... 14:41:52 <ajayaa> isviridov, I didn't get you. 14:43:01 <isviridov> ajayaa : there is a list of apis to restict, and we have monitoring api now 14:43:35 <ajayaa> isviridov, got you! okay. 14:43:39 <isviridov> ajayaa : anyhow great spec! 14:43:56 <ajayaa> isviridov, We can add it later by filing a bug and then fixing it. 14:44:36 <isviridov> Yeap 14:45:49 <isviridov> Team, anything else to discuss now? 14:46:28 <isviridov> Seems we are done 14:46:45 <ikhudoshyn> looks like 14:46:47 <charlesw> I have a spec WIP, not ready yet. But I'd like to hear your use cases and comments. https://wiki.openstack.org/wiki/MagnetoDB/specs/requestmetrics 14:47:22 <isviridov> charlesw : the first q why not in spec repo? 14:48:16 <isviridov> #link https://wiki.openstack.org/wiki/MagnetoDB/specs/requestmetrics 14:48:23 <charlesw> @isviridov, can you educate us on the process? 14:48:55 <ikhudoshyn> the same as with our usual repo 14:49:04 <ikhudoshyn> but magnetodb-specs 14:49:31 <ikhudoshyn> git clone, branch, set up git-review, commit, git review 14:49:48 <isviridov> charlesw : I've seen something similar in swift. So, actually it is one more monitoring 14:50:12 <charlesw> I was using our wiki template: https://wiki.openstack.org/wiki/MagnetoDB/specs/template 14:51:45 <isviridov> charlesw : why not put it as a part of monitoring api? 14:52:09 <charlesw> I looked at swift as well they have 3 different ways: recon, informant, and statsd w/o middleware 14:53:03 <charlesw> we don't need an API for monitoring. We can publish it thru statsd/graphite/ganglia/etc 14:53:36 <charlesw> similar to swift 14:53:45 <isviridov> charlesw : yes we can, but in such case we are loosing this information for celiometer 14:54:21 <isviridov> charlesw : what do you think? 14:54:44 <charlesw> right, there are some areas unclear like whether to use/work with ceilometer 14:55:03 <charlesw> that's the kind of comments I'd like to hear more:) 14:56:16 <isviridov> Ok, I think that would be greate to keep it under Monitoring API as one source of cluster metrics. And call it via any monitoring solutions like nagios so on. 14:56:40 <miqui_____> ..even sensuapp 14:57:40 <isviridov> charlesw : how fast do you need it? 14:58:01 <charlesw> @isviridov, I'll think about it. Thanks for comments. 14:58:36 <charlesw> probably the week after thanksgiving 14:58:59 <isviridov> Another approach can be just implement it for statsd as it is easier and faster, and move to Monitoring API just solution is more or less machure. 14:59:28 <charlesw> the overhead/perf impact can be big 14:59:31 <isviridov> With Monitoring API we have to implement own storage to keep data about every node 15:00:05 <isviridov> charlesw : what performance impact do you mean? 15:00:39 * isviridov time is over 15:00:43 <charlesw> we need to capture metrics for every request. For statsd, just udp post can be done. 15:00:58 <charlesw> got to go, have another meeting 15:01:20 <isviridov> charlesw : but data can be cashed and agregted in memory 15:01:23 <isviridov> charlesw : sure 15:01:32 <isviridov> Thank you everybody for comming 15:01:39 <isviridov> #endmeeting