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