14:00:19 <isviridov> #startmeeting magnetodb
14:00:20 <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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <openstack> The meeting name has been set to 'magnetodb'
14:00:33 <openstackgerrit> Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification  https://review.openstack.org/137336
14:00:42 <isviridov> It is holyday in US, so Symantec is not with us today
14:00:48 <isviridov> ikhudoshyn hi
14:00:55 <isviridov> dukhlov are you with us?
14:00:58 <ominakov> o/
14:01:12 <isviridov> ominakov o/
14:01:14 <dukhlov> \o_
14:01:26 * isviridov strange smile...
14:02:01 <isviridov> Let us go througt action items from last meeting
14:02:15 <openstackgerrit> Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification  https://review.openstack.org/137336
14:02:22 <isviridov> #topic Go through action items isviridov
14:02:38 <rushiagr> o/
14:02:39 <achuprin_> o/
14:02:46 <aostapenko> hi
14:02:50 <isviridov> It seems the only one was to review RBAC implementation
14:03:01 <isviridov> rushiagr o/
14:03:16 <isviridov> aostapenko ikhudoshyn ajayaa dukhlov anythin to discuss here?
14:03:33 <isviridov> #link https://review.openstack.org/#/c/124391/
14:04:16 <ajayaa> There is a bug here. Unless we check the existence of a project with keystone, RBAC wouldn't work as expected.
14:04:53 <isviridov> ajayaa does it mean call to keystone on every request?
14:05:10 <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:25 <ajayaa> isviridov, possibly!
14:05:50 * isviridov surprised
14:06:08 <ajayaa> isviridov, Anyway by using keystone tokens we are making a call to keystone.
14:06:17 <dukhlov> why is current approach not good?
14:06:19 <isviridov> What the thing is? Desn't PKI tiken contatin roles as well?
14:06:47 <dukhlov> I mean checking that project_id == token's tenant
14:06:47 <isviridov> ajayaa it is expected to use PKI token and avoid call to ks
14:07:34 <ajayaa> isviridov, PKI tokens are very long. Do you want the users to send an additional payload of 10 KB each time.
14:07:52 <ajayaa> I think we discussed this sometime back.
14:08:37 <ajayaa> dukhlov, In that case you wouldn't be allowing an admin access to projects other than project embedded in his token.
14:08:58 <ajayaa> By admin, I mean someone who has access to all other projects.
14:09:02 <dukhlov> ajayaa, clear
14:09:32 <ajayaa> AFAIK, most of the deployments use UUID tokens as of now, isviridov
14:09:55 <ajayaa> There was survey done by keystone-devs sometime back.
14:10:25 <dukhlov> but I thought that admin role allows user to get token for any tenant and then sent it to target service
14:10:27 <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:41 <ikhudoshyn> ajayaa: in fact we fought to avoid asking ks each time, so I think we do want PKI
14:11:18 <dukhlov> maybe your approach is good, but anyway we need to check how another services like nova handles this
14:11:25 <ajayaa> ikhudoshyn, sorry. perhaps I was not present in that discussion.
14:11:39 <ikhudoshyn> ajayaa: np, its just fyi
14:11:44 <ajayaa> dukhlov, exactly. Let me see!
14:12:17 <ajayaa> move on?
14:13:42 <isviridov> #action ajayaa clarify auth in nova
14:13:46 <isviridov> ajayaa sounds good?
14:15:14 <ajayaa> yes
14:15:17 <ajayaa> isviridov
14:15:24 <isviridov> Ok, move on
14:15:38 <isviridov> #topic Authentication issues with monitoring API for third party services ominakov
14:16:13 <isviridov> ominakov?
14:17:07 <isviridov> I believer I can start in behalh ominakov
14:17:28 <ominakov> yep, as you know we have some issues with monitoring api
14:17:45 <isviridov> Yeap, please go on
14:17:56 <ominakov> i describe issues and suggestions in https://blueprints.launchpad.net/magnetodb/+spec/api-uri-format-change
14:18:47 <isviridov> The thing is to make urls
14:18:50 <isviridov> v1/data/<tenant_id>/...
14:18:50 <isviridov> v1/monitoring/<tenant_id>/...
14:19:07 <isviridov> the different applications
14:19:19 <dukhlov> looks good!
14:19:25 <isviridov> ikhudoshyn?
14:19:32 <ikhudoshyn> agree
14:20:04 <ominakov> i think, i can do this
14:20:12 <isviridov> ominakov bp has been approved. I believe documentaton should be also updated.
14:20:22 <ominakov> isviridov, sure
14:21:01 <isviridov> dukhlov ikhudoshyn do we need spec for this?
14:21:26 <ikhudoshyn> just update existing docs
14:21:31 <dukhlov> agree
14:22:03 <ikhudoshyn> BP with couple lines description would be enuff just to track activities
14:22:30 <isviridov> Ok, let us move on
14:22:54 <isviridov> I see no ther topics in agenda except open discussion
14:22:59 <isviridov> #topic  Open discussion isviridov
14:23:15 <aostapenko> Lets see...
14:23:38 <ajayaa> Why do we want to create a separate application for dynamodb-api?
14:23:38 <isviridov> aostapenko any progress with lookup table by uuid?
14:24:21 <aostapenko> https://review.openstack.org/#/c/137336/ Here are specs
14:24:40 <isviridov> ajayaa in order to manage it separately during deployment. Balance requests, deploy on separate hardware so on.
14:24:48 <dukhlov> we have already created separate application for magnetoDB as far as I know
14:24:58 <isviridov> ajayaa but it is nice to have
14:25:07 <dukhlov> I mean WSGI application
14:26:36 <isviridov> dukhlov yes
14:26:53 <dukhlov> and not we can deploy it with MagnetoDB API as composite application (using paste) or run as separate process
14:27:56 <ajayaa> dukhlov, okay!
14:29:34 <isviridov> dukhlov with gunicorn deployment you are right, all port management is moved to higher level
14:29:58 <isviridov> dukhlov that is why it is nice to have]
14:31:02 <isviridov> dukhlov I mean to say, that separate process is not needed it this case, but separate WSGI app is
14:31:58 <isviridov> aostapenko +2 to https://review.openstack.org/#/c/137336/
14:32:14 <dukhlov> isviridov: at least we are providing deployment flexibility
14:32:24 <isviridov> dukhlov agree
14:33:45 <isviridov> Do we have anything else to discuss/highligt?
14:34:03 <aostapenko> isviridov thanks
14:34:51 <ikhudoshyn> isviridov: not from my side
14:35:04 <isviridov> aostapenko ominakov ajayaa rushiagr?
14:35:23 <ajayaa> no from me. Thanks
14:35:58 <ominakov> nope
14:36:10 <isviridov> Thanks everybody for comming
14:36:13 <isviridov> #endmeeting