| *** Viswanath has joined #magnetodb | 00:17 | |
| *** Viswanath has quit IRC | 00:20 | |
| *** charlesw has joined #magnetodb | 01:23 | |
| *** jeromatron has joined #magnetodb | 02:58 | |
| *** jeromatron has quit IRC | 02:59 | |
| *** jeromatron has joined #magnetodb | 03:04 | |
| *** jeromatron has quit IRC | 03:12 | |
| *** jeromatr_ has joined #magnetodb | 03:12 | |
| *** jeromatr_ has quit IRC | 03:17 | |
| *** igormarnat_ has joined #magnetodb | 04:11 | |
| *** igormarnat has quit IRC | 04:12 | |
| *** igormarnat_ is now known as igormarnat | 04:12 | |
| *** rushiagr_away is now known as rushiagr | 04:27 | |
| *** vivekd has joined #magnetodb | 04:39 | |
| *** jeromatron has joined #magnetodb | 04:43 | |
| *** charlesw has quit IRC | 04:48 | |
| openstackgerrit | Merged stackforge/magnetodb: Include correct URL in JSON response for "list tables" call https://review.openstack.org/132707 | 04:52 |
|---|---|---|
| *** jeromatron has quit IRC | 04:59 | |
| *** jeromatron has joined #magnetodb | 05:01 | |
| *** jeromatron has quit IRC | 05:13 | |
| *** jeromatron has joined #magnetodb | 05:14 | |
| *** vivekd has quit IRC | 05:36 | |
| *** jeromatr_ has joined #magnetodb | 05:38 | |
| *** jeromatron has quit IRC | 05:38 | |
| *** jeromatron has joined #magnetodb | 05:41 | |
| *** jeromatr_ has quit IRC | 05:41 | |
| *** vivekd has joined #magnetodb | 05:45 | |
| *** jeromatron has quit IRC | 05:52 | |
| *** jeromatron has joined #magnetodb | 05:52 | |
| *** ajayaa has joined #magnetodb | 05:58 | |
| *** vivekd has quit IRC | 06:05 | |
| *** jeromatron has quit IRC | 06:08 | |
| *** k4n0 has joined #magnetodb | 06:09 | |
| *** vivekd has joined #magnetodb | 06:09 | |
| *** romainh has joined #magnetodb | 08:09 | |
| *** ajayaa has quit IRC | 08:36 | |
| *** ajayaa has joined #magnetodb | 09:31 | |
| *** vivekd has quit IRC | 12:23 | |
| *** ajayaa has quit IRC | 12:35 | |
| *** ajayaa has joined #magnetodb | 12:48 | |
| ajayaa | Hi guys! | 12:59 |
| ajayaa | Are we having a meeting today? | 12:59 |
| ajayaa | dukhlov ikhudoshyn isviridov ^^ | 13:00 |
| rushiagr | hello! | 13:00 |
| ajayaa | HI rushiagr. | 13:01 |
| rushiagr | DST strikes again? :) | 13:01 |
| ikhudoshyn | hi guys | 13:04 |
| ikhudoshyn | yes we are | 13:04 |
| ikhudoshyn | isviridov will join us in a couple minutes | 13:05 |
| isviridov_away | ajayaa : rushiagr ikhudoshyn hello everybody | 13:10 |
| *** isviridov_away is now known as isviridov | 13:10 | |
| rushiagr | hello! | 13:11 |
| ajayaa | Hi. | 13:11 |
| isviridov | Do you have time shift in your time zone? | 13:11 |
| isviridov | I expected that we have meeting in 1 hour and our coleagues from Symantec as well, I believe | 13:11 |
| rushiagr | not in India | 13:12 |
| isviridov | I see. This week we have equal time difference with US, so I would keep it at 4 PM EET and 9 AM EST. | 13:16 |
| isviridov | I've updated wiki actually https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Nov_13.2C_2014.2C_14:00_UTC | 13:16 |
| isviridov | rushiagr : ajayaa sorry for inconvenience | 13:17 |
| ajayaa | isviridov, np | 13:17 |
| isviridov | rushiagr : ajayaa are you able to join us in 43 mins? | 13:17 |
| rushiagr | isviridov: no probls | 13:18 |
| rushiagr | isviridov: I am doubtful. Can't say for sure | 13:18 |
| isviridov | rushiagr : anyhow you are very welcome | 13:18 |
| rushiagr | isviridov: thanks :) | 13:18 |
| *** miqui has joined #magnetodb | 13:31 | |
| *** achuprin_ has joined #magnetodb | 13:51 | |
| *** rushiagr is now known as rushiagr_away | 13:51 | |
| *** charlesw has joined #magnetodb | 13:53 | |
| *** nunosantos has joined #magnetodb | 13:54 | |
| *** dukhlov_ has joined #magnetodb | 13:55 | |
| isviridov | Hello everybody | 14:00 |
| isviridov | It is meeting time | 14:00 |
| charlesw | Hi guys | 14:01 |
| nunosantos | hello | 14:01 |
| dukhlov_ | hi | 14:01 |
| isviridov | ikhudoshyn : dukhlov nunosantos ajayaa charlesw rushiagr_away hello | 14:01 |
| ominakov | hello | 14:01 |
| isviridov | #startmeeting isviridov | 14:01 |
| openstack | Meeting started Thu Nov 13 14:01:31 2014 UTC and is due to finish in 60 minutes. The chair is isviridov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| ikhudoshyn | o/ | 14:01 |
| openstack | The meeting name has been set to 'isviridov' | 14:01 |
| ajayaa | Hi all! | 14:01 |
| isviridov | o/ | 14:01 |
| achuprin_ | o/ | 14:02 |
| isviridov | romainh: ? | 14:02 |
| nunosantos | o/ | 14:02 |
| romainh | isviridov: yep | 14:03 |
| isviridov | Ok, let us start | 14:03 |
| ajayaa | o/ | 14:03 |
| isviridov | #topic action items | 14:03 |
| isviridov | #1 dukhlov data encryption support blueprint | 14:03 |
| dukhlov_ | a'm working on it now and plan to finish spec this week | 14:04 |
| dukhlov_ | also draft for managment API is under review now | 14:05 |
| dukhlov_ | it is dependency for encryption bp | 14:05 |
| isviridov | I see #link https://review.openstack.org/#/c/133505/ | 14:05 |
| dukhlov_ | but it has -1 from jenkisn | 14:05 |
| ikhudoshyn | guys, sry, coult u remind me address of our meeting page | 14:05 |
| isviridov | yeap | 14:05 |
| dukhlov_ | sorry I will fix it | 14:06 |
| isviridov | ikhudoshyn : here it is https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Nov_13.2C_2014.2C_14:00_UTC | 14:06 |
| ikhudoshyn | isviridov, tnx | 14:06 |
| isviridov | Ok, dukhlov leaving AI on you | 14:06 |
| isviridov | #action dukhlov data encryption support blueprint | 14:06 |
| dukhlov_ | sure | 14:07 |
| isviridov | #2 ikhudoshyn file a bug about dynamodb version support documentation | 14:07 |
| *** keith_newstadt has joined #magnetodb | 14:07 | |
| isviridov | ikhudoshyn : any success? | 14:07 |
| ikhudoshyn | my bad, forgot bout it | 14:07 |
| ajayaa | #help what is the idea behind storage before create_table? | 14:07 |
| isviridov | keith_newstadt : GM | 14:07 |
| isviridov | ajayaa : what do you mean?\ | 14:08 |
| keith_newstadt | morning all | 14:08 |
| isviridov | ikhudoshyn : leaving on you as well | 14:08 |
| ikhudoshyn | sure | 14:09 |
| isviridov | #action ikhudoshyn file a bug about dynamodb version support documentation | 14:09 |
| ajayaa | The high level meaning of storage! | 14:09 |
| ajayaa | Is storage a high level container for tables? | 14:10 |
| *** k4n0 has quit IRC | 14:10 | |
| ajayaa | Does it deal with amount of space being used by tables? | 14:10 |
| isviridov | ajayaa : dukhlov seems there we need a bit more context | 14:10 |
| dukhlov_ | storage is like keyspace for cassandra | 14:10 |
| dukhlov_ | it seems ajayaa is talking about managment API bp | 14:11 |
| ajayaa | okay. But we have a high level container called tenant for tables. | 14:11 |
| openstackgerrit | Ilya Sviridov proposed stackforge/magnetodb-specs: Add specification for part of Management API https://review.openstack.org/133505 | 14:11 |
| ajayaa | I am looking at https://review.openstack.org/#/c/133505/1/specs/kilo/approved/managment-api-for-tenent-configuration-spec.rst | 14:11 |
| dukhlov_ | yes, for no storage=tenant | 14:12 |
| dukhlov_ | now | 14:12 |
| dukhlov_ | but tenant is openstack-wide container | 14:12 |
| ikhudoshyn | dukhlov_, any plans for them to diverge? | 14:12 |
| dukhlov_ | not for now | 14:12 |
| ajayaa | If we add storage entity, then different users could have same table name in the same tenant. | 14:13 |
| ajayaa | Am I right? | 14:13 |
| dukhlov_ | but I want to consider this usecase for future | 14:13 |
| dukhlov_ | and make implementation with possibility to ve extended | 14:13 |
| ajayaa | Can you please tell me another usecase? | 14:14 |
| ikhudoshyn | hm.. in our current API we have 1 tenant = 1 keyspace | 14:14 |
| dukhlov_ | sure | 14:14 |
| ajayaa | ikhudoshyn, +1 | 14:14 |
| ikhudoshyn | but for mgmt you want it different, why? | 14:14 |
| keith_newstadt | so far, the use case is simply that we want to provide encrypted tenants | 14:14 |
| dukhlov_ | when 1 tenant can have a few storages | 14:14 |
| ikhudoshyn | looks like YAGNI for me | 14:14 |
| dukhlov_ | 1 more nested level | 14:14 |
| keith_newstadt | i don't think we have a use case for different encryption settings for tables within a tenant | 14:15 |
| keith_newstadt | i'd be concerned about adding unnecessary complexity... | 14:15 |
| keith_newstadt | thoughts? | 14:15 |
| ajayaa | keith_newstadt +1 | 14:15 |
| dukhlov_ | but also storage can have another settings | 14:15 |
| dukhlov_ | lilke consystency level for example | 14:16 |
| ikhudoshyn | at least i'd like to see data API and mgmt API consistent to each other | 14:16 |
| dukhlov_ | I don't sugget add comlexity now | 14:16 |
| ikhudoshyn | dukhlov_, how could this affect existing data API? | 14:16 |
| dukhlov_ | I only sugget to leave posibility to improve it in fute without changins ofxisting feature | 14:17 |
| ikhudoshyn | YAGNI | 14:18 |
| dukhlov_ | ikhudoshyn: for now - it don't affect API | 14:18 |
| keith_newstadt | i'd think consistency would be an attribute of a table, rather than a tenant or storage | 14:18 |
| dukhlov_ | but it is not possible for Cassandra | 14:18 |
| keith_newstadt | storage settings would be specifically for... storage attributes. rather than for API related attributes. | 14:18 |
| dukhlov_ | it is attribute of keyspace | 14:18 |
| keith_newstadt | we can't set quorum settings (required number of reads, e.g.) on a particular table or read/write operation? | 14:19 |
| dukhlov_ | we can | 14:20 |
| charlesw | yes each query can set its tunable CL | 14:20 |
| dukhlov_ | but we can't set how many replicas we have | 14:20 |
| dukhlov_ | per table | 14:20 |
| keith_newstadt | i think number of replicas would be fine as a per tenant setting | 14:21 |
| keith_newstadt | makes setting quotas and showback easier as well | 14:21 |
| charlesw | Can you change the config after initial setting? | 14:22 |
| dukhlov_ | yes agree, drafted bp use only one storage for tenant | 14:22 |
| dukhlov_ | no | 14:23 |
| dukhlov_ | only remove all storage and then initialize it again | 14:23 |
| keith_newstadt | should probably reject requests to POST to an existing storage | 14:24 |
| keith_newstadt | require explicit DELETE before a rePOST | 14:24 |
| dukhlov_ | yes | 14:24 |
| isviridov | dukhlov keith_newstadt ajayaa we are at the very beginning of BP discussion, so feel free to comment the spec | 14:26 |
| * isviridov just remind | 14:26 | |
| dukhlov_ | yes it would be great | 14:26 |
| keith_newstadt | will do | 14:27 |
| isviridov | ajayaa : next topic? | 14:27 |
| ikhudoshyn | let's move on | 14:28 |
| achuprin_ | +1 | 14:28 |
| isviridov | #3 isviridov ikhudoshyn clarify roadmap item | 14:28 |
| ikhudoshyn | we kinda did | 14:28 |
| isviridov | So, before summit there was an item about DymanoDB support here https://etherpad.openstack.org/p/magnetodb-kilo-roadmap | 14:29 |
| isviridov | ikhudoshyn : yeap, just sharing with team | 14:29 |
| isviridov | As you know Amazon has released the new version of API with GlobalIndex support, map data type support and expression in querie... | 14:30 |
| isviridov | So, we have defined the scope as AWS DynamoDB API 2011-12-05 version. | 14:31 |
| isviridov | The documenntation is still available for downloading in PDF format | 14:31 |
| isviridov | ajayaa : rushiagr_away any thoughts? | 14:31 |
| isviridov | Ok, just let us move on. | 14:33 |
| isviridov | ajayaa : rushiagr_away would be nice to hear from you later | 14:33 |
| isviridov | #topic Open discussion | 14:33 |
| ikhudoshyn | i'm working on backup/restore 4 mdb | 14:34 |
| ikhudoshyn | https://review.openstack.org/#/c/133933/ -- it's a draft for API | 14:34 |
| ikhudoshyn | pls review and share yr thoughts | 14:34 |
| keith_newstadt | we had an interesting discussion with the trove folks at the conference | 14:35 |
| ikhudoshyn | pls note, the abocve doc is API spec only, it's not about impl | 14:35 |
| keith_newstadt | it occurred to us all that there will be some overlap in what we are designing | 14:35 |
| ikhudoshyn | about to delegate lo level maintenance to trove? | 14:35 |
| keith_newstadt | magnetodb is a service on the data path, where trove is a db provisioning api | 14:35 |
| keith_newstadt | the backup api's overlap between the two | 14:36 |
| keith_newstadt | wondering if this is an opportunity for us to collaborate - at least to have consistent apis, possibly to use trove's cassandra support for backup/restore under magnetodb | 14:36 |
| keith_newstadt | it would require some additional functionality from the trove folks - e.g. per tenant/keyspace backup | 14:37 |
| keith_newstadt | ikhudoshyn: thoughts on that? | 14:37 |
| ikhudoshyn | well, trove was the 1st thing I looked at | 14:37 |
| ikhudoshyn | when working on API | 14:37 |
| ikhudoshyn | tried to make it alike but not follow it exactly | 14:38 |
| keith_newstadt | do you think there are reasons to diverge from the trove api? | 14:38 |
| keith_newstadt | or could we consolidate on a single interface? | 14:38 |
| ikhudoshyn | as for collaborating, 1st thing is, when will they be ready for prod use? | 14:38 |
| keith_newstadt | it's a good question. i don't think they have been thinking about per keyspace backup until now. so i wouldn't expect them to be moving as quickly as we are in this direction | 14:39 |
| keith_newstadt | but we could start working with them on the api design, with plans to either move the functinoality into trove, or for us to develop it directly into trove | 14:40 |
| ikhudoshyn | I think I should recheck their API once again just to see if there are real blokers for us to have a single api | 14:41 |
| isviridov | What about import/export fucntionality? | 14:41 |
| ikhudoshyn | that was my #2 | 14:41 |
| ajayaa | Hi guys. Sorry had a meeting. | 14:41 |
| keith_newstadt | what are the difference between the use cases for import/export and backup/restore? | 14:41 |
| keith_newstadt | i'm picturing import/export to be more magnetodb specific | 14:42 |
| ikhudoshyn | the API I worked on supports backup in DB agnistic format | 14:42 |
| keith_newstadt | +1 | 14:42 |
| isviridov | It looks for me that we can use the same API but with somethink like a type ir strategy: backend_database_native or magentodb | 14:42 |
| ikhudoshyn | so user coudl have all his data in json format and could download it | 14:42 |
| charlesw | backup/restore should be operational/system, import/export is user data, logical level | 14:43 |
| ikhudoshyn | i proposed 'strategy' param for 'create backup' call | 14:43 |
| keith_newstadt | generally i would use import/export when i want to get the data in a generalized format so that i could bring it into another application or db | 14:43 |
| keith_newstadt | charlesw: +1 | 14:43 |
| keith_newstadt | so import/export would be magnetodb specific, where backup/restore could be via trove | 14:44 |
| isviridov | charlesw : do you think we have to keep two APIs for that? export/import and backup/restore? | 14:44 |
| isviridov | keith_newstadt: ? | 14:44 |
| ajayaa | When we use trove for backup, do we have to provision cassandra through trove only? | 14:44 |
| charlesw | yes, we should have admin API | 14:45 |
| keith_newstadt | i don't think so | 14:45 |
| ikhudoshyn | ajayaa, seems like yes | 14:45 |
| keith_newstadt | hm. why? | 14:45 |
| ikhudoshyn | from what i remember, trove stores meta info about its deployments | 14:46 |
| ajayaa | But all deployers might not want to go with trove reasons being cassandra performance on vms with shared disk. | 14:46 |
| ikhudoshyn | as well as we do for our tables | 14:46 |
| ikhudoshyn | so for trove to be able to backup our C* we should pass all meta they need | 14:46 |
| ikhudoshyn | in short, this would require a deeper integration, than just calling trove api | 14:47 |
| isviridov | Trove relies on agent working on each Cassandra node, so you can backup only provisioned by Trove database | 14:47 |
| keith_newstadt | if we were to implement backup/restore without trove, would we need an agent on each node as well? | 14:48 |
| ikhudoshyn | isviridov, +1, this is for the case of DB-aware backups | 14:48 |
| ajayaa | I feel that we could have two implementation on with trove and one without trove. | 14:48 |
| keith_newstadt | seems wasteful to implement it twice... | 14:48 |
| ikhudoshyn | the 'pro' of db agnostic backup -- we don't need any additional code on DB nodes | 14:48 |
| ikhudoshyn | ajayaa, keith_newstadt, in fact this could be chosen via strategy | 14:49 |
| keith_newstadt | the 'con' would be performance and backup size | 14:49 |
| ajayaa | keith_newstadt, In trove case we wouldn't have to do much, because trove will take care of it. | 14:49 |
| ikhudoshyn | keith_newstadt, sure | 14:49 |
| keith_newstadt | we would need an agent on the cassandra nodes as well to do backup/restore, right? | 14:50 |
| keith_newstadt | (for the more performant version) | 14:50 |
| ikhudoshyn | definitely | 14:50 |
| ikhudoshyn | anyway, in order to use Trove's backup we shoul deploy our C* via trove | 14:50 |
| keith_newstadt | how would we provision that agent, if we assume we weren't using trove? | 14:50 |
| ikhudoshyn | the same way we provision C* | 14:51 |
| ajayaa | ikhudoshyn +1 | 14:51 |
| keith_newstadt | so we would provide instructions to the operator on how to deploy cassandra, and then our agent on top | 14:52 |
| keith_newstadt | and they would use heat or puppet or whatever to implement it. | 14:52 |
| keith_newstadt | is that right? | 14:52 |
| ikhudoshyn | yes | 14:52 |
| ajayaa | +1 | 14:52 |
| isviridov | keith_newstadt ikhudoshyn I would suggest defining own backup/restore API and implement it to operate JSONs only. Also leave a stub for future DB-aware implementation. Just we have it in Trove we can employ it and ahve another backup/restore mechanis | 14:52 |
| keith_newstadt | couldn't we still use the same agent as trove, or a subset of it | 14:52 |
| keith_newstadt | and then it is a question of whether trove deploys that agent, or if the operator does through heat/puppet/etc | 14:53 |
| openstackgerrit | Merged stackforge/magnetodb: Adds Cassandra implemetation of monitoring API https://review.openstack.org/132267 | 14:53 |
| isviridov | keith_newstadt : they deploys an agent via cloud-init and prebuild images | 14:53 |
| ikhudoshyn | once again trove-guestagent is tightly relies on the whole trove codebase as well as on trove's db with meta. its mysql for now | 14:53 |
| charlesw | fyi, Netflix Priam has jar files inside C*, runs along with Cassandra. Could be another option | 14:54 |
| keith_newstadt | we should consider meeting with the trove folks to discuss | 14:54 |
| ajayaa | keith_newstadt, +1 | 14:55 |
| keith_newstadt | as for db-agnostic backup/restore, we should talk about the functionality. sounds more like import/export, which is slightly different functionality-wise | 14:55 |
| isviridov | I believe that Trove weekly meeting is the best option | 14:55 |
| keith_newstadt | e.g. import is additive rather than overwrite, doesn't support incrementals, etc | 14:55 |
| *** denis_makogon has joined #magnetodb | 14:56 | |
| keith_newstadt | k. i also know the tesora folks, and could reach out to them if that would be useful | 14:56 |
| isviridov | denis_makogon : hi | 14:56 |
| isviridov | keith_newstadt : export/import sounds not quite right, but the reason was not divede it from backup/restore. | 14:57 |
| denis_makogon | isviridov, hi | 14:57 |
| ajayaa | denis_makogon, In trove do we have an option of deploying cassandra nodes on bare metal? | 14:58 |
| ajayaa | In other words does it use ironic? | 14:58 |
| keith_newstadt | isviridov: ok. we can discuss the details in the context of the blueprint | 14:58 |
| denis_makogon | ajayaa, no | 14:58 |
| denis_makogon | ajayaa, it's up to nova | 14:58 |
| isviridov | keith_newstadt : but with defining type or strategy for backup, we can remove it | 14:58 |
| denis_makogon | ajayaa, fyi bare metal is not main steam any more - docker/lxc rules the world =) | 14:59 |
| isviridov | * deprecate | 14:59 |
| keith_newstadt | denis_makogon: also not yet supported :) | 14:59 |
| denis_makogon | keith_newstadt, by whom ? | 14:59 |
| ajayaa | denis_makogon, that is for the cool kids. :) | 15:00 |
| keith_newstadt | trove. or am i wrong? | 15:00 |
| ajayaa | Not prod-ready I believe. | 15:00 |
| denis_makogon | keith_newstadt, trove would speak only to nova, but nova can run over tons of drivers including lxc/docker/ironic | 15:00 |
| keith_newstadt | prod ready? | 15:00 |
| *** jeromatron has joined #magnetodb | 15:00 | |
| ajayaa | keith_newstadr, Would you really run cassandra or any other prod application on docker, as it stands today? | 15:01 |
| ajayaa | keith_newstadt ^^ | 15:01 |
| * isviridov meeting time is over. But let us finish discussion if you don't mind | 15:02 | |
| ikhudoshyn | ajayaa, +1 ) | 15:02 |
| keith_newstadt | +1 | 15:02 |
| ajayaa | btw, https://review.openstack.org/#/c/124391/ is up for review. :) | 15:03 |
| isviridov | Ok, let us talk to Trove guys | 15:03 |
| keith_newstadt | and i think we should hammer out our use cases for backup/restore | 15:03 |
| isviridov | #idea we should hammer out our use cases for backup/restore | 15:04 |
| isviridov | #idea deprecate export/import API and use backup/restore instead | 15:04 |
| keith_newstadt | goals for talking to trove would be (1) can we avoid having two different apis for db backup/restore inside of openstack and (2) can we avoid having two different implementations of that api | 15:04 |
| isviridov | #help | 15:05 |
| keith_newstadt | isviridov: +1 | 15:05 |
| isviridov | #action keith_newstadt isviridov ikhudoshyn clarify if we can avoid having two different apis for db backup/restore inside of openstack | 15:06 |
| ikhudoshyn | denis_makogon, btw, does Trove have any publised spec for backup/restore API? | 15:06 |
| denis_makogon | ikhudoshyn, sure it has | 15:06 |
| isviridov | #action keith_newstadt isviridov ikhudoshyn clarify if we can avoid having two different implementations of that api | 15:07 |
| ikhudoshyn | could you point me? | 15:07 |
| denis_makogon | #link https://wiki.openstack.org/wiki/Trove/snapshot-design | 15:07 |
| ikhudoshyn | tnx | 15:07 |
| isviridov | Sorry guys, return back to you later | 15:07 |
| isviridov | #endmeeting | 15:07 |
| openstack | Meeting ended Thu Nov 13 15:07:33 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:07 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/isviridov/2014/isviridov.2014-11-13-14.01.html | 15:07 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/isviridov/2014/isviridov.2014-11-13-14.01.txt | 15:07 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/isviridov/2014/isviridov.2014-11-13-14.01.log.html | 15:07 |
| *** isviridov is now known as isviridov_away | 15:07 | |
| ikhudoshyn | keith_newstadt, a quick look at the trove's spec shows it is per instance | 15:09 |
| ikhudoshyn | which is really inappropriate for C* | 15:09 |
| keith_newstadt | ya. we also need it to be per tenant. | 15:10 |
| keith_newstadt | so definitely need some discussion around it | 15:10 |
| keith_newstadt | it's possible that it won't be a good fit, but i think the your point about per node backup will affect the trove guys as much as us. need a solution | 15:11 |
| ikhudoshyn | ok, we should definitely visit trovians | 15:11 |
| denis_makogon | ikhudoshyn, it's a gap for Trove which is pretty valid in general, i've spoke with couple trove cores and they are ok with such thing, but we need to have spec for it | 15:11 |
| ikhudoshyn | denis_makogon, could you also pls remind, when your weekly meeting usually happens? | 15:12 |
| denis_makogon | yesterday =) | 15:12 |
| ikhudoshyn | denis_makogon, great)) | 15:12 |
| ikhudoshyn | was it the really last? | 15:12 |
| *** jeromatron has quit IRC | 15:12 | |
| *** jeromatron has joined #magnetodb | 15:13 | |
| ikhudoshyn | i mean just point us to the schedule pls)) | 15:13 |
| *** ajayaa has quit IRC | 15:13 | |
| denis_makogon | https://wiki.openstack.org/wiki/Meetings/TroveMeeting | 15:16 |
| ikhudoshyn | tnx | 15:16 |
| *** jeromatr_ has joined #magnetodb | 15:17 | |
| *** jeromatron has quit IRC | 15:17 | |
| *** rushiagr_away is now known as rushiagr | 15:38 | |
| *** jeromatr_ has quit IRC | 15:46 | |
| *** jeromatron has joined #magnetodb | 15:46 | |
| ikhudoshyn | o/ | 15:58 |
| *** jeromatr_ has joined #magnetodb | 16:20 | |
| *** jeromatron has quit IRC | 16:22 | |
| *** dukhlov_ has quit IRC | 16:27 | |
| *** keith_newstadt has quit IRC | 16:28 | |
| *** keith_newstadt has joined #magnetodb | 16:30 | |
| *** jeromatr_ has quit IRC | 16:32 | |
| *** jeromatron has joined #magnetodb | 16:32 | |
| *** jeromatron has quit IRC | 16:35 | |
| *** jeromatron has joined #magnetodb | 16:35 | |
| *** romainh has left #magnetodb | 16:41 | |
| *** ajayaa has joined #magnetodb | 16:42 | |
| *** jeromatron has quit IRC | 16:55 | |
| *** jeromatron has joined #magnetodb | 16:58 | |
| *** ajayaa has quit IRC | 17:02 | |
| *** rushiagr is now known as rushiagr_away | 17:07 | |
| *** miqui has quit IRC | 17:08 | |
| *** miqui has joined #magnetodb | 17:11 | |
| *** openstackgerrit has quit IRC | 17:34 | |
| *** openstackgerrit has joined #magnetodb | 17:34 | |
| *** vnaboychenko has joined #magnetodb | 17:39 | |
| openstackgerrit | Nuno Santos proposed stackforge/magnetodb: Get correct username from HTTP header https://review.openstack.org/134313 | 17:54 |
| *** openstackgerrit has quit IRC | 18:03 | |
| *** openstackgerrit has joined #magnetodb | 18:04 | |
| *** openstackgerrit has quit IRC | 18:49 | |
| *** openstackgerrit has joined #magnetodb | 18:49 | |
| *** openstackgerrit has quit IRC | 19:18 | |
| *** openstackgerrit has joined #magnetodb | 19:19 | |
| *** romainh has joined #magnetodb | 20:04 | |
| *** keith_newstadt has quit IRC | 20:04 | |
| *** openstackgerrit has quit IRC | 20:04 | |
| *** openstackgerrit has joined #magnetodb | 20:05 | |
| *** nunosantos has left #magnetodb | 20:08 | |
| *** nunosantos has joined #magnetodb | 20:23 | |
| *** charlesw has quit IRC | 21:06 | |
| *** openstackgerrit has quit IRC | 21:19 | |
| *** openstackgerrit has joined #magnetodb | 21:19 | |
| *** romainh has left #magnetodb | 21:42 | |
| *** nunosantos has quit IRC | 21:54 | |
| *** denis_makogon has quit IRC | 23:47 | |
| *** denis_makogon has joined #magnetodb | 23:47 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!