Thursday, 2014-10-30

*** vnaboychenko has joined #magnetodb00:29
*** vnaboychenko has quit IRC00:49
*** vnaboychenko has joined #magnetodb00:49
*** charlesw has joined #magnetodb00:50
*** vnaboychenko has quit IRC00:53
*** openstackgerrit has joined #magnetodb01:32
*** vnaboychenko has joined #magnetodb02:52
*** charlesw has quit IRC03:10
*** openstackgerrit has quit IRC03:10
*** vnaboychenko has quit IRC03:34
*** anteaya has quit IRC03:37
*** vivekd has joined #magnetodb03:39
*** anteaya has joined #magnetodb03:45
*** jeromatron has joined #magnetodb04:01
*** jeromatron has quit IRC04:02
*** jeromatron has joined #magnetodb04:03
*** jeromatron has quit IRC04:04
*** jeromatron has joined #magnetodb04:08
*** jeromatron has quit IRC04:28
*** jeromatron has joined #magnetodb04:31
*** keith_newstadt has joined #magnetodb04:45
*** keith_newstadt has quit IRC04:49
*** keith_newstadt has joined #magnetodb04:50
*** vivekd has quit IRC04:52
*** vivekd has joined #magnetodb04:52
*** jeromatron has quit IRC05:37
*** ajayaa has joined #magnetodb05:48
*** rushiagr_away is now known as rushiagr05:54
*** rushiagr is now known as rushiagr_away05:57
*** ajayaa has quit IRC06:33
*** ajayaa has joined #magnetodb06:35
*** k4n0 has joined #magnetodb06:37
*** ajaya has joined #magnetodb06:47
*** ajayaa has quit IRC07:13
*** ajaya has quit IRC07:14
*** ajayaa has joined #magnetodb07:14
*** achuprin_ has quit IRC07:25
*** keith_newstadt has quit IRC07:25
*** tnurlygayanov has quit IRC08:07
*** tnurlygayanov has joined #magnetodb08:19
*** romainh has joined #magnetodb08:25
*** isviridov_away is now known as isviridov08:34
romainhisviridov: hi, where can I find the topics of the design session?08:54
isviridovromainh : hello09:01
isviridovI believe we will go through roadmap and blueprints we have in scope now09:02
isviridovActually I'm thinking how to run the session, as far as there will be not so mush mdb developers to make it really technical09:03
isviridovromainh : any ideas what your wolud like to discuss?09:03
romainhisviridov: some weeks ago you said that we will talk about multiple DC deployment. It's a good idea.09:12
romainhisviridov: and what about multi tenancy?09:13
isviridovromainh: yeap, multidc is a good topic, however currently the priority for it became lower09:14
isviridovromainh : what do you mean saying multi tenancy?09:15
isviridovI believe we have it completely.09:15
romainhisviridov: I think about multi-tenant capabilities in Cassandra: request scheduler, potential arena allocation issues, security, ...09:17
romainhisviridov: what is the hottest topic right now?09:20
isviridovromainh : I see, do you think you can draft a spec and we can add it as one of topics to discuss?09:21
isviridovromainh : the hottest now is integration with celiometer and data encryption09:23
isviridovromainh : I believe the last one is more hot09:23
romainhisviridov: hmm... time is running out. What should be the deadline to submit the spec in order to add it to the session?09:25
isviridovromainh : have you ever been on openstack summit before?09:26
romainhisviridov: no, it's the first time09:28
isviridovIt goes in following way, usually there are several topics to discuss, each of community member presents its own with spec, demo or something. During the presentations the audience is giving the feedback and ideas.09:31
isviridovSo, answering your question I would add multi dc to schedule if you can run it. I think about 15 mins09:32
isviridovspec is a great way to share your thoughts, but etherpad could be also good09:32
isviridovI've started one for design session in general https://etherpad.openstack.org/p/magnetodb-kilo-design-summit09:36
isviridovFeel free to add what do your want to discuss and/or create new one09:36
isviridovromainh09:37
idegtiarovHi! I've improved spec please take a look when you'll have free time https://review.openstack.org/#/c/131764/10:15
isviridovidegtiarov : great news10:16
idegtiarovisviridov: :)10:17
isviridovLet me look at it10:17
isviridovidegtiarov : any plans to touch dynamodb part?10:17
idegtiarovisviridov: I haven't look at dynamodb part yet. let me start from the openstack part10:22
isviridovidegtiarov : ok, but it also exists ;)10:23
idegtiarovisviridov: shall I mentioned in spec dynamodb part?10:23
isviridovYes, please. A well as streaming-api.10:24
idegtiarovisviridov: I am going to remove Router class, so no doubts that dynamodb part would be also migrate10:24
isviridovOk, let us also explicitly highlingt that streaming api wouldn't be touched in scope of this BP10:25
*** isviridov is now known as isviridov_away10:30
idegtiarovisviridov_away: Done10:31
*** miqui has joined #magnetodb12:15
*** isviridov_away is now known as isviridov12:44
*** jeromatron has joined #magnetodb13:07
*** charlesw has joined #magnetodb13:10
isviridovHello guys, I was just remided that we have a meeting today :)13:18
isviridovThere was a time shift, so we will have meeting in 40 mins13:18
*** jeromatron has quit IRC13:19
*** keith_newstadt has joined #magnetodb13:19
isviridovSorry for inconvenience13:20
isviridovkeith_newstadt : meeting will start in 40 mins because of timeshoft13:21
isviridovkeith_newstadt : hello13:21
*** jeromatron has joined #magnetodb13:21
isviridovTill then here is roadmap fro kilo https://etherpad.openstack.org/p/magnetodb-kilo-roadmap13:22
isviridovFeel free to comment13:22
*** jeromatron has quit IRC13:23
*** boris-42 has joined #magnetodb13:25
keith_newstadtisviridov: sounds good13:28
*** ajayaa has quit IRC13:36
*** keith_newstadt has quit IRC13:37
*** keith_newstadt has joined #magnetodb13:37
*** jeromatron has joined #magnetodb13:42
*** vivekd has quit IRC13:55
isviridovHello everyone13:59
isviridovdukhlov : ikhudoshyn charlesw aostapenko it is meeting time14:00
*** rushiagr_away is now known as rushiagr14:00
isviridovHello rushiagr14:00
ikhudoshyno/14:00
aostapenkoo/14:00
dukhlovo/14:00
isviridovikhudoshyn : let me start it firs )14:00
nunosantoso/14:00
aostapenko\o/14:00
rushiagro/14:00
isviridov#startmeeting magentodb14:00
openstackMeeting started Thu Oct 30 14:00:52 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
openstackThe meeting name has been set to 'magentodb'14:00
rushiagrwow, entry at just about the right time :)14:00
isviridovFeel free to wave :)14:01
dukhlovo\/_\/14:01
nunosantoso/14:01
isviridovrushiagr : it is becayse of time shift14:01
*** jeromatron has quit IRC14:01
charleswo/14:01
rushiagrisviridov: okay14:01
rushiagro\14:01
isviridovrushiagr : works only for today meeting14:01
isviridovLet us start gentlmen14:02
*** jeromatron has joined #magnetodb14:02
isviridovHelo jeromatron14:02
jeromatronHi14:02
isviridovToday agenda https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Oct_30.2C_2014.2C_14:00_UTC14:02
isviridovjeromatron : welcome to mdb meeting14:03
jeromatronthanks :)14:03
ominakovhello, guys14:03
*** ajayaa has joined #magnetodb14:03
isviridov#topic action items14:03
isviridovominakov : hello14:03
isviridovYou know last time meetbot didn't work, not sure that I remember all of them14:03
ajayaaHi All.14:04
isviridovajayaa : hello14:04
isviridovI could say that we have discussed celiomete integration with ajayaa14:04
isviridovajayaa : any success with spec?14:05
ajayaaisviridov, I was trying to create an example sample.14:05
isviridov#link https://review.openstack.org/#/c/126335/14:05
ajayaaWhen I am done with that I will update the spec. One of the comment by reviewers asks about example sample.14:06
isviridovok, I want to have it lookng good for summit. Ping me if you can't finish today or tomorrow14:07
isviridovI would back you up14:07
ajayaaisviridov, okay. Thanks14:07
isviridovdukhlov : any update with cassandra backend v2 blueprint?14:08
isviridovBTW we have 3 specs approved for kilo aleady #link http://magnetodb-specs.readthedocs.org/en/latest/14:09
dukhlovI've started to write spec. As you know I created CUSTOM secondary index implementation for Cassandra14:09
dukhlovand there a lot of staff to be described14:09
* isviridov thanks to ominakov idegtiarov achudnovets and others14:09
isviridovdukhlov : any draft available?14:10
dukhlovin progress14:11
isviridov:)14:11
dukhlovno draft for now14:11
isviridovAny other action items to discuss?14:11
ikhudoshynlet's go forward14:12
* isviridov next topic is on the way14:12
isviridov#topic Kilo roadmap https://etherpad.openstack.org/p/kilo-crossproject-summit-topics isviridov14:12
isviridovYeap, we have it14:12
ikhudoshynhttps://etherpad.openstack.org/p/magnetodb-kilo-roadmap14:13
isviridov#link https://etherpad.openstack.org/p/magnetodb-kilo-roadmap14:13
isviridovikhudoshyn : thank you14:13
isviridovThere are comments14:13
isviridovikhudoshyn : export/import api is about data backup/restore but database agnostic14:14
ikhudoshynisviridov: tnx14:14
charleswis it per tenant/table?14:15
isviridovcharlesw : I see it as per table14:15
ikhudoshynisviridov: for me export/import sounds like a have an artifact that represents my data14:16
ikhudoshynbut backup/restore sounds more like a fact that this artifact is being stored (more like a service)14:17
isviridovYeap, artifact stored somewhere in swift14:17
ikhudoshynso we do mean import/export to/from swift?14:17
charleswso the exported data should include all my data row, and my table schema, but not index?14:17
ikhudoshyncharlesw: if it is DB agnistic than yes14:18
ikhudoshyns/than/then14:18
isviridovikhudoshyn : probably wording is not the best, just didn't want to use backup/restore as it sounds really connected to cassandra. We can say that it will be big jsons in swift14:19
isviridovcharlesw : data, schema the magentodb one, so index are build during import14:20
isviridov* indexes14:20
ikhudoshyni didn't mean it is connected to C*, just wanted behavior like 'backup my data' -> 'your data has been backed up'14:20
ikhudoshynon some external storage14:21
isviridovikhudoshyn : yeap14:21
charleswsounds good. Is swift just an option, or the only way14:21
isviridovcharlesw : just an option, I believe small ammounts of data could be imported/exported from client directly14:23
charlesw+114:24
isviridovcharlesw : ikhudoshyn let us move on14:25
ikhudoshynisviridov: ok14:25
isviridovdukhlov : data encryption support?14:25
*** ajayaa has quit IRC14:25
dukhlovhm14:26
dukhlovactually it is only idea14:26
dukhlovI think that it is interesting  feature to store data securely on disk14:28
dukhlovI saw this feature in Datastax Enterprise14:28
dukhlovand I believe that we need to think about how we can implement it14:29
isviridovdukhlov : will you blueprint it? I can be good topic to discuss on summit14:29
isviridov* it14:29
dukhlovso I'm going to investigate alternatives and prepare plueprint specification soon14:30
dukhlov*blueprint14:30
isviridov!m dukhlov14:30
[o__o]You're doing good work, dukhlov!14:30
openstackisviridov: Error: "m" is not a valid command.14:30
isviridov#action dukhlov data encryption support blueprint14:31
isviridovikhudoshyn: what do you mean     Catch up with the latest DynamoDB API?14:31
ikhudoshynas far as i know they updated their DynamoDB API14:32
isviridovAs I know they have added GlobalIndexes and regexps on conditions at least14:32
ikhudoshynsince we claim we support Amazon DynamoDB as well we should consider supporting those new features as wel14:32
charleswhbase has the Transparent table/CF encryption implemented: https://issues.apache.org/jira/browse/HBASE-754414:33
ikhudoshynat least we should review changes and figure out can we support them14:33
isviridovcharlesw : good to know14:33
isviridovikhudoshyn : yeap, we have to clear stand what version of dynamo api we do support14:34
*** k4n0 has quit IRC14:34
isviridovWill you file a bug for documentation of it?14:34
isviridovikhudoshyn: ?14:34
ikhudoshynцшдд вщ14:34
ikhudoshynwill do14:34
isviridov#action ikhudoshyn file a bug about dynamodb version support documentation14:35
romainhabout data encryption: what about client-to-node and node-to-node encryption?14:35
isviridovikhudoshyn : let us rephrase your statement in etherpad, not it sounds really huge14:35
charleswalso this is relatively new to dynamo14:35
charlesw ConditionalOperator14:35
charlesw    Important14:35
charlesw    There is a newer parameter available. Use ConditionExpression instead. Note that if you use ConditionalOperator and ConditionExpression at the same time, DynamoDB will return a ValidationException exception.14:36
charlesw    This parameter does not support lists or maps.14:36
charleswwe don't support it right now14:36
isviridovikhudoshyn : what about like cover gap with dynamo db api 2011-12-05 version14:37
ikhudoshynisviridov: sounds good14:37
dukhlovromainh: client-to-node means encrypt data on client side and sent to cassandra already encrypted?14:37
isviridovcharlesw : yeap, there should be clear line we don't have now14:38
dukhlovromainh: what does node-to-node mean?14:38
isviridovikhudoshyn : done14:38
romainhdukhlov: yes14:38
romainhdukhlov: when data are sent from one node to another, data could be encrypted by C*14:39
dukhlovromainh: client-to-node encryption is possible but in this case we will lose possibility to perform range query14:39
dukhlovbecause ordering will be lost14:40
isviridovromainh : the client-cassandra connection is done in secure part of network, I think we can rely on general security policies for infrastructure14:40
romainhdukhlov: no, the communication is made over SSL14:40
romainhisviridov: ok14:41
charleswencryption for data at rest, over the wire is doen by ssl?14:41
dukhlovas far as I know C* has possibility to communicate with other nodes using ssl encryption but it only save us from traffic sniffing14:41
isviridovmdb client ---- HTTPS --->{ mdb api ---- TCP--> Cassandra}14:42
dukhlovbut data will be stored not encrypted to sstables14:42
isviridov{} - secure network not reachable for mdb user14:42
romainhdukhlov: exactly14:42
romainhit prevents from traffic sniffing14:43
dukhlovso this blueprint is aimed to prevent getting data from disk14:44
romainhso, your unique concern is about disk encryption, right?14:44
isviridovikhudoshyn : how do you see 'Provide operability of the existing DynamoDB API with new data types (lists, dicts)'?14:44
romainhok14:44
dukhlovyes14:44
ikhudoshynisviridov: i don't see it yet actually. But one will definitely get in trouble if he tries to access an existind table with maps and lists via AWS API14:45
ikhudoshynso my point for now is, we should provide some workaround or data transformation for that14:46
isviridovikhudoshyn : I think we have to hide tabels created via DynamoDB API from those what were created via mdb API and vice versa14:46
isviridovikhudoshyn : exactly the same approach C* has with CQL tables and column families. What do you think?14:47
ikhudoshynisviridov: this could be done easily, but first I'd like to look for some other ways14:48
ikhudoshynor we'll end up with two separate products14:48
charlesw+1 for keeping data separate14:49
isviridovIt is a big topic, let us rephrase it in etherpad somehow. Now it sounds like a big challenge14:50
isviridovLet us move on and do it offline14:51
isviridovikhudoshyn : sounds ok?14:51
ikhudoshynisviridov: +114:51
isviridov#action isviridov ikhudoshyn clarify roadmap item14:51
isviridov#topic Design session topics https://etherpad.openstack.org/p/magnetodb-kilo-design-summit isviridov14:51
*** miqui has quit IRC14:51
isviridovHere is a current work-in-progress design session schedule, feel free to suggest topics14:52
isviridovThis summit we have 90 mins14:52
isviridov#topic Next meeting isviridov14:53
isviridov#info the next week meeting is canceled due to summit14:53
isviridov#Open discussion isviridov14:54
aostapenkoI suggest to extend healthcheck request so it will check rpc and additionally return name of host, that responses this request. So it can be used multiple times thru the load balancer and all magnetodb nodes can be checked by multiple healthcheck requests14:54
isviridovaostapenko: ?14:54
isviridovaostapenko : how can you manage what node to send to?14:55
charleswhow do you make sure all MDB nodes will be pinged by load balancer?14:56
isviridovcharlesw : +114:56
dukhlovcharlesw:+114:56
isviridovaostapenko : why do we need it?14:56
dukhlovisviridov: +114:56
isviridovdukhlov : +114:57
dukhlovhandshake14:57
aostapenkocharlesw: only 1 node will be pinged by load balancer. But we will send many requests, and each response will contain info about the node that responded14:57
*** jeromatron has quit IRC14:57
isviridovaostapenko : healthcheck request is not designed to be called out of balancer by user.14:58
isviridovIt should be called by LB and it will call each node14:58
aostapenkoisviridov: sounds reasonable, I think this diagnostics should be implemented another way15:00
* isviridov it is time for next meeting15:00
isviridovI believe we are done for today15:00
charleswLB should provide status of wheather an MDB node is up/down15:00
isviridovThank you everybody for coming15:00
isviridovaostapenko : thank you for your ideas15:01
isviridovSee you after summit15:01
charleswthanks for organizing15:01
isviridov#endmeeting15:01
openstackMeeting ended Thu Oct 30 15:01:15 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.html15:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.txt15:01
openstackLog:            http://eavesdrop.openstack.org/meetings/magentodb/2014/magentodb.2014-10-30-14.00.log.html15:01
dukhlovo-/\-/\15:01
charleswo-/\-/\15:01
isviridovdukhlov : charlesw no ideas what it is :)15:02
dukhlov)))15:02
*** isviridov is now known as isviridov_away15:02
charleswhave to hit back :)15:02
*** keith_newstadt has quit IRC15:06
*** jeromatron has joined #magnetodb15:10
*** jeromatron has quit IRC15:29
*** charlesw has quit IRC15:46
*** jeromatron has joined #magnetodb15:48
*** romainh has quit IRC15:52
*** romainh has joined #magnetodb16:10
*** jeromatron has quit IRC16:21
*** jeromatron has joined #magnetodb16:22
*** isviridov_away changes topic to "MagnetoDB - key-value store for OpenStack (https://wiki.openstack.org/wiki/MagnetoDB, logs @ https://botbot.me/freenode/magnetodb/) | Our Kilo OpenStack summit design session http://goo.gl/czt5mL | Kilo roadmap http://goo.gl/XHXIpg | ask isviridov is any Qs"16:31
*** jeromatron has quit IRC17:23
*** jeromatron has joined #magnetodb17:29
*** jeromatron has quit IRC18:01
*** jeromatron has joined #magnetodb18:05
*** vnaboychenko has joined #magnetodb18:22
*** vnaboych_ has joined #magnetodb19:20
*** vnaboyc__ has joined #magnetodb19:21
*** vnaboych_ has quit IRC19:21
*** rushiagr is now known as rushiagr_away19:22
*** vnaboychenko has quit IRC19:23
*** jeromatron has quit IRC20:18
*** jeromatron has joined #magnetodb20:19
*** jeromatron has quit IRC20:44
*** jeromatron has joined #magnetodb20:58
*** romainh has left #magnetodb21:01
*** vnaboyc__ has quit IRC21:08
*** denis_makogon_ has joined #magnetodb21:36
*** jeromatron has quit IRC22:27
*** jeromatron has joined #magnetodb22:29
*** jeromatron has quit IRC22:37
*** jeromatron has joined #magnetodb22:42
*** jeromatron has quit IRC22:57
*** jeromatron has joined #magnetodb22:59
*** jeromatron has quit IRC23:15
*** jeromatron has joined #magnetodb23:16
*** jeromatron has quit IRC23:24
*** jeromatron has joined #magnetodb23:26
*** jeromatron has quit IRC23:36
*** denis_makogon_ has quit IRC23:45
*** boris-42 has quit IRC23:45
*** boris-42 has joined #magnetodb23:50

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!