| *** jeromatron has joined #magnetodb | 00:02 | |
| *** denis_makogon has quit IRC | 00:16 | |
| *** jeromatron has quit IRC | 00:27 | |
| *** charlesw has quit IRC | 02:16 | |
| *** charlesw has joined #magnetodb | 02:45 | |
| *** rushiagr_away is now known as rushiagr | 03:28 | |
| *** rushiagr is now known as rushiagr_away | 04:15 | |
| *** rushiagr_away is now known as rushiagr | 05:06 | |
| *** ajayaa has joined #magnetodb | 05:21 | |
| *** charlesw has quit IRC | 05:57 | |
| *** k4n0 has joined #magnetodb | 06:26 | |
| *** denis_makogon has joined #magnetodb | 08:25 | |
| *** romainh has joined #magnetodb | 09:08 | |
| rushiagr | hello magnetoDB :) | 09:53 |
|---|---|---|
| rushiagr | I see a decorator on tests: @attr(type=['CreT-44']) | 09:54 |
| rushiagr | what does it mean? | 09:54 |
| isviridov | rushiagr hello | 10:55 |
| isviridov | it is test case code accroding to master test paln https://docs.google.com/a/mirantis.com/spreadsheets/d/1mZbJluIAUprA7tayiVe9owZXyEmAOipvIzPoY5Z44aE/edit#gid=1926165037 | 10:56 |
| isviridov | Means Create Table functionality test case #44 | 10:56 |
| isviridov | rushiagr such a process was used on first stages of development | 10:57 |
| rushiagr | isviridov: oh, cool | 10:57 |
| rushiagr | isviridov: maybe a mention of the spreadsheet somewhere in the code, or wiki would make it more obvious.. | 10:58 |
| isviridov | ominakov is it the latest version of this doc we have? | 10:58 |
| ominakov | isviridov, yep | 10:58 |
| isviridov | rushiagr I think yes, it should be. However currently process has changed and we are adding tests with feature at the same time | 10:59 |
| isviridov | ominakov thx | 10:59 |
| ominakov | rushiagr, sounds good | 10:59 |
| rushiagr | isviridov: okay. I just want our code to make sense, otherwise wanderers like me will wonder what CreT-43 means. :) | 11:00 |
| *** denis_makogon has quit IRC | 11:00 | |
| isviridov | rushiagr great~ | 11:03 |
| openstackgerrit | Dmitriy Ukhlov proposed stackforge/magnetodb-specs: Add cassandra-backend-implementation-redesign blueprint spec https://review.openstack.org/137379 | 11:29 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 12:25 |
| *** k4n0 has quit IRC | 12:26 | |
| ajayaa | ikhudoshyn, aostapenko, Currently the code does not allow you to operate on projects which does not match context's project. | 13:00 |
| ajayaa | And that is right because if you are not using keystone library to check existence of a project, you could potentially be creating a keyspace corresponding to a non-existent project in keystone. | 13:01 |
| ajayaa | After my patch, it would allow to operate on projects which exists in keystone but would never create a keyspace corresponding to a non existent project. | 13:03 |
| ajayaa | Only problem is error code returned to the user. | 13:03 |
| ajayaa | And that should come in a different patch. | 13:03 |
| ajayaa | Line number 32 is never reached in current code. | 13:04 |
| ajayaa | It reaches only if the url's project and context's project match. | 13:05 |
| aostapenko | You are right here, however if you run magnetodb with your code with policy allowing everything, and put valid token, that refers to tenant different from tenant in url, the tenant from token will be used for acting with resources. That is unexpected | 13:06 |
| aostapenko | ajayaa | 13:06 |
| aostapenko | In this case we need an additional check that tenant from url exists in keystone | 13:08 |
| ajayaa | Yes. Exactly. And after that use project_id from url and perform operations on it. | 13:10 |
| ajayaa | And not user project_id from context. | 13:11 |
| ajayaa | use* | 13:11 |
| isviridov | Today's agenda https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Nov_27.2C_2014.2C_14:00_UTC | 13:52 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 13:53 |
| isviridov | aostapenko you are fast. Please look at my comment about spec name | 13:57 |
| isviridov | Hello everybody I believe we can start weekly meeting | 14:00 |
| ikhudoshyn | o/ | 14:00 |
| isviridov | #startmeeting magnetodb | 14:00 |
| openstack | Meeting started Thu Nov 27 14:00:19 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 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| openstack | The meeting name has been set to 'magnetodb' | 14:00 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 14:00 |
| isviridov | It is holyday in US, so Symantec is not with us today | 14:00 |
| isviridov | ikhudoshyn hi | 14:00 |
| isviridov | dukhlov are you with us? | 14:00 |
| ominakov | o/ | 14:00 |
| isviridov | ominakov o/ | 14:01 |
| dukhlov | \o_ | 14:01 |
| * isviridov strange smile... | 14:01 | |
| isviridov | Let us go througt action items from last meeting | 14:02 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 14:02 |
| isviridov | #topic Go through action items isviridov | 14:02 |
| rushiagr | o/ | 14:02 |
| achuprin_ | o/ | 14:02 |
| aostapenko | hi | 14:02 |
| isviridov | It seems the only one was to review RBAC implementation | 14:02 |
| isviridov | rushiagr o/ | 14:03 |
| isviridov | aostapenko ikhudoshyn ajayaa dukhlov anythin to discuss here? | 14:03 |
| isviridov | #link https://review.openstack.org/#/c/124391/ | 14:03 |
| ajayaa | There is a bug here. Unless we check the existence of a project with keystone, RBAC wouldn't work as expected. | 14:04 |
| isviridov | ajayaa does it mean call to keystone on every request? | 14:04 |
| ajayaa | I am interested to know how other projects handle this situation, since most of other components work with project_ids in their URL. | 14:05 |
| ajayaa | isviridov, possibly! | 14:05 |
| * isviridov surprised | 14:05 | |
| ajayaa | isviridov, Anyway by using keystone tokens we are making a call to keystone. | 14:06 |
| dukhlov | why is current approach not good? | 14:06 |
| isviridov | What the thing is? Desn't PKI tiken contatin roles as well? | 14:06 |
| dukhlov | I mean checking that project_id == token's tenant | 14:06 |
| isviridov | ajayaa it is expected to use PKI token and avoid call to ks | 14:06 |
| ajayaa | isviridov, PKI tokens are very long. Do you want the users to send an additional payload of 10 KB each time. | 14:07 |
| ajayaa | I think we discussed this sometime back. | 14:07 |
| ajayaa | dukhlov, In that case you wouldn't be allowing an admin access to projects other than project embedded in his token. | 14:08 |
| ajayaa | By admin, I mean someone who has access to all other projects. | 14:08 |
| dukhlov | ajayaa, clear | 14:09 |
| ajayaa | AFAIK, most of the deployments use UUID tokens as of now, isviridov | 14:09 |
| ajayaa | There was survey done by keystone-devs sometime back. | 14:09 |
| dukhlov | but I thought that admin role allows user to get token for any tenant and then sent it to target service | 14:10 |
| isviridov | ajayaa it was discussed before and we have decided that it is not bad, PKI token without catalog is not verly long and is about 1KB | 14:10 |
| ikhudoshyn | ajayaa: in fact we fought to avoid asking ks each time, so I think we do want PKI | 14:10 |
| dukhlov | maybe your approach is good, but anyway we need to check how another services like nova handles this | 14:11 |
| ajayaa | ikhudoshyn, sorry. perhaps I was not present in that discussion. | 14:11 |
| ikhudoshyn | ajayaa: np, its just fyi | 14:11 |
| ajayaa | dukhlov, exactly. Let me see! | 14:11 |
| ajayaa | move on? | 14:12 |
| isviridov | #action ajayaa clarify auth in nova | 14:13 |
| isviridov | ajayaa sounds good? | 14:13 |
| ajayaa | yes | 14:15 |
| ajayaa | isviridov | 14:15 |
| isviridov | Ok, move on | 14:15 |
| isviridov | #topic Authentication issues with monitoring API for third party services ominakov | 14:15 |
| isviridov | ominakov? | 14:16 |
| isviridov | I believer I can start in behalh ominakov | 14:17 |
| ominakov | yep, as you know we have some issues with monitoring api | 14:17 |
| isviridov | Yeap, please go on | 14:17 |
| ominakov | i describe issues and suggestions in https://blueprints.launchpad.net/magnetodb/+spec/api-uri-format-change | 14:17 |
| isviridov | The thing is to make urls | 14:18 |
| isviridov | v1/data/<tenant_id>/... | 14:18 |
| isviridov | v1/monitoring/<tenant_id>/... | 14:18 |
| isviridov | the different applications | 14:19 |
| dukhlov | looks good! | 14:19 |
| isviridov | ikhudoshyn? | 14:19 |
| ikhudoshyn | agree | 14:19 |
| ominakov | i think, i can do this | 14:20 |
| isviridov | ominakov bp has been approved. I believe documentaton should be also updated. | 14:20 |
| ominakov | isviridov, sure | 14:20 |
| isviridov | dukhlov ikhudoshyn do we need spec for this? | 14:21 |
| ikhudoshyn | just update existing docs | 14:21 |
| dukhlov | agree | 14:21 |
| ikhudoshyn | BP with couple lines description would be enuff just to track activities | 14:22 |
| isviridov | Ok, let us move on | 14:22 |
| isviridov | I see no ther topics in agenda except open discussion | 14:22 |
| isviridov | #topic Open discussion isviridov | 14:22 |
| aostapenko | Lets see... | 14:23 |
| ajayaa | Why do we want to create a separate application for dynamodb-api? | 14:23 |
| isviridov | aostapenko any progress with lookup table by uuid? | 14:23 |
| aostapenko | https://review.openstack.org/#/c/137336/ Here are specs | 14:24 |
| isviridov | ajayaa in order to manage it separately during deployment. Balance requests, deploy on separate hardware so on. | 14:24 |
| dukhlov | we have already created separate application for magnetoDB as far as I know | 14:24 |
| isviridov | ajayaa but it is nice to have | 14:24 |
| dukhlov | I mean WSGI application | 14:25 |
| isviridov | dukhlov yes | 14:26 |
| dukhlov | and not we can deploy it with MagnetoDB API as composite application (using paste) or run as separate process | 14:26 |
| ajayaa | dukhlov, okay! | 14:27 |
| isviridov | dukhlov with gunicorn deployment you are right, all port management is moved to higher level | 14:29 |
| isviridov | dukhlov that is why it is nice to have] | 14:29 |
| isviridov | dukhlov I mean to say, that separate process is not needed it this case, but separate WSGI app is | 14:31 |
| isviridov | aostapenko +2 to https://review.openstack.org/#/c/137336/ | 14:31 |
| dukhlov | isviridov: at least we are providing deployment flexibility | 14:32 |
| isviridov | dukhlov agree | 14:32 |
| isviridov | Do we have anything else to discuss/highligt? | 14:33 |
| aostapenko | isviridov thanks | 14:34 |
| ikhudoshyn | isviridov: not from my side | 14:34 |
| isviridov | aostapenko ominakov ajayaa rushiagr? | 14:35 |
| ajayaa | no from me. Thanks | 14:35 |
| *** rushiagr has quit IRC | 14:35 | |
| ominakov | nope | 14:35 |
| isviridov | Thanks everybody for comming | 14:36 |
| isviridov | #endmeeting | 14:36 |
| openstack | Meeting ended Thu Nov 27 14:36:13 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:36 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-11-27-14.00.html | 14:36 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-11-27-14.00.txt | 14:36 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-11-27-14.00.log.html | 14:36 |
| isviridov | ominakov bp has been approved (just added workitems) | 14:36 |
| ominakov | isviridov, ok | 14:37 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 14:51 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 14:53 |
| *** rushiagr_away has joined #magnetodb | 15:04 | |
| *** rushiagr_away is now known as rushiagr | 15:11 | |
| rushiagr | my IRC bouncer was stuck by a DoS I think, so got disconnected :/ | 15:13 |
| *** charlesw has joined #magnetodb | 15:57 | |
| *** charlesw has quit IRC | 16:46 | |
| *** charlesw has joined #magnetodb | 17:06 | |
| *** rushiagr is now known as rushiagr_away | 17:11 | |
| *** charlesw has quit IRC | 17:38 | |
| *** ajayaa has quit IRC | 17:43 | |
| *** rushiagr_away is now known as rushiagr | 18:02 | |
| *** romainh has quit IRC | 18:15 | |
| *** miarmak has joined #magnetodb | 18:23 | |
| *** rushiagr is now known as rushiagr_away | 18:48 | |
| *** miarmak_ has joined #magnetodb | 18:51 | |
| *** miarmak has quit IRC | 18:51 | |
| *** rushiagr_away is now known as rushiagr | 18:56 | |
| *** charlesw has joined #magnetodb | 19:44 | |
| *** charlesw has quit IRC | 22:09 | |
| *** charlesw has joined #magnetodb | 22:12 | |
| *** denis_makogon has joined #magnetodb | 22:33 | |
| *** denis_makogon has quit IRC | 22:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!