| *** jeromatron has quit IRC | 00:01 | |
| *** charlesw has joined #magnetodb | 01:13 | |
| *** charlesw has quit IRC | 02:38 | |
| *** charlesw has joined #magnetodb | 02:42 | |
| *** charlesw has quit IRC | 02:47 | |
| *** vivekd has joined #magnetodb | 03:04 | |
| *** charlesw has joined #magnetodb | 03:06 | |
| *** vivekd_ has joined #magnetodb | 04:11 | |
| *** vivekd has quit IRC | 04:13 | |
| *** vivekd_ is now known as vivekd | 04:13 | |
| openstackgerrit | Charles Wang proposed stackforge/magnetodb-specs: Add request metrics speccification https://review.openstack.org/138950 | 04:26 |
|---|---|---|
| *** charlesw has quit IRC | 04:40 | |
| *** rushiagr_away is now known as rushiagr | 04:48 | |
| *** vivekd has quit IRC | 04:52 | |
| *** vivekd has joined #magnetodb | 04:53 | |
| *** vivekd has quit IRC | 04:54 | |
| *** vivekd has joined #magnetodb | 04:55 | |
| *** vivekd has quit IRC | 04:57 | |
| *** vivekd has joined #magnetodb | 04:59 | |
| *** vivekd has joined #magnetodb | 05:00 | |
| *** vivekd has quit IRC | 05:00 | |
| *** vivekd has joined #magnetodb | 05:01 | |
| *** vivekd has quit IRC | 05:01 | |
| *** vivekd has joined #magnetodb | 05:02 | |
| *** ajayaa has joined #magnetodb | 05:45 | |
| *** jeromatron has joined #magnetodb | 06:09 | |
| *** vivekd_ has joined #magnetodb | 06:11 | |
| *** vivekd has quit IRC | 06:12 | |
| *** vivekd_ is now known as vivekd | 06:13 | |
| *** k4n0 has joined #magnetodb | 06:54 | |
| *** jeromatron has quit IRC | 07:20 | |
| *** achuprin_ has quit IRC | 07:29 | |
| *** jeromatron has joined #magnetodb | 07:33 | |
| *** achuprin_ has joined #magnetodb | 07:43 | |
| *** denis_makogon has joined #magnetodb | 07:59 | |
| *** jeromatron has quit IRC | 08:06 | |
| *** jeromatron has joined #magnetodb | 08:49 | |
| *** jeromatron has quit IRC | 08:50 | |
| *** vivekd has quit IRC | 08:51 | |
| *** jeromatron has joined #magnetodb | 08:56 | |
| *** romainh has joined #magnetodb | 09:17 | |
| *** jeromatron has quit IRC | 09:17 | |
| *** jeromatron has joined #magnetodb | 09:21 | |
| *** jeromatron has quit IRC | 09:23 | |
| *** jeromatron has joined #magnetodb | 09:26 | |
| *** jeromatron has quit IRC | 09:56 | |
| *** jeromatron has joined #magnetodb | 10:06 | |
| *** jeromatron has quit IRC | 10:11 | |
| openstackgerrit | Oleksandr Minakov proposed stackforge/magnetodb: API URI format change https://review.openstack.org/138059 | 10:54 |
| *** isviridov_away is now known as isviridov | 10:56 | |
| *** jeromatron has joined #magnetodb | 11:23 | |
| *** denis_makogon has quit IRC | 11:43 | |
| *** dmakogon_ is now known as denis_makogon | 11:44 | |
| *** denis_makogon_ has joined #magnetodb | 11:44 | |
| *** jeromatron has quit IRC | 11:50 | |
| *** denis_makogon_ has quit IRC | 11:51 | |
| openstackgerrit | Oleksandr Minakov proposed stackforge/magnetodb: API URI format change https://review.openstack.org/138059 | 11:55 |
| *** jeromatron has joined #magnetodb | 11:57 | |
| openstackgerrit | Oleksandr Minakov proposed stackforge/magnetodb: Fixes doc according to API refactoring https://review.openstack.org/139035 | 12:21 |
| openstackgerrit | Oleksandr Minakov proposed stackforge/magnetodb: Fixes doc according to API refactoring https://review.openstack.org/139035 | 12:21 |
| openstackgerrit | Ilya Sviridov proposed stackforge/magnetodb: oslo.messaging update https://review.openstack.org/139038 | 12:36 |
| isviridov | Hello everybody. | 12:40 |
| isviridov | We have py27 job broken because of olso.messaging 1.5.0 release. | 12:40 |
| openstackgerrit | Illia Khudoshyn proposed stackforge/magnetodb: (WIP)Add backup/restore REST API methods https://review.openstack.org/137328 | 12:40 |
| isviridov | Should be fixed with https://review.openstack.org/139038 | 12:41 |
| *** jeromatron has quit IRC | 12:41 | |
| *** isviridov 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 | gate-magnetodb-python27 is broken. Should be fixed with https://review.openstack.org/139038" | 12:42 | |
| isviridov | aostapenko agenda has been updated | 12:49 |
| isviridov | aostapenko I've just noticed your item and I believe that adding the links will be useful | 12:54 |
| aostapenko | isviridov: yes, thank you | 12:54 |
| *** Jon___ has joined #magnetodb | 13:55 | |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 13:57 |
| isviridov | Hello everybody | 13:58 |
| isviridov | It is meeting time | 13:59 |
| achuprin_ | Hi team | 14:00 |
| isviridov | ikhudoshyn dukhlov achudnovets aostapenko ominakov achuprin mdb meeting | 14:00 |
| isviridov | #startmeeting magnetodb | 14:00 |
| openstack | Meeting started Thu Dec 4 14:00:33 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 |
| isviridov | Hi everyone | 14:00 |
| ominakov | Hello guys | 14:00 |
| isviridov | o/ | 14:00 |
| ominakov | o/ | 14:01 |
| isviridov | ominakov hello | 14:01 |
| achudnovets | hi guys | 14:01 |
| isviridov | achudnovets welcome back | 14:01 |
| ikhudoshyn | o/ | 14:01 |
| aostapenko | o/ | 14:01 |
| isviridov | So today meeting agenda is following https://wiki.openstack.org/wiki/MagnetoDB/WeeklyMeetingAgenda#Agenda | 14:02 |
| isviridov | I think we can start | 14:02 |
| *** nunosantos has joined #magnetodb | 14:02 | |
| isviridov | #topic Go through action items isviridov | 14:02 |
| isviridov | ajayaa clarify auth in nova | 14:03 |
| nunosantos | o/ | 14:03 |
| isviridov | hi nunosantos | 14:03 |
| * isviridov doesn't see ajayaa | 14:03 | |
| isviridov | Let us go through other topics | 14:04 |
| isviridov | #topic Add proposition to add availability to describe table by its uuid aostapenko | 14:04 |
| *** avinogradov has joined #magnetodb | 14:04 | |
| isviridov | #link https://review.openstack.org/137336 | 14:05 |
| isviridov | aostapenko? | 14:05 |
| aostapenko | please review a specification shared by isviridov | 14:05 |
| *** miqui_ has joined #magnetodb | 14:06 | |
| aostapenko | we are proposing to add an availability to use table uuid in any url, that contains table name | 14:06 |
| ajayaa | Oh hi! Sorry, I am late. | 14:06 |
| ajayaa | I will update nova-auth in the end. | 14:07 |
| aostapenko | and describe, create, delete and list operations will additionally contain table uuid | 14:07 |
| ikhudoshyn | aostapenko: and we should add uuid in all tersponses that contain table info (describe, delete) | 14:07 |
| ikhudoshyn | aostapenko: u were faster | 14:07 |
| isviridov | ajayaa hi, we would love to hear from you | 14:07 |
| ajayaa | now? | 14:08 |
| isviridov | ajayaa later | 14:08 |
| aostapenko | Does any body have any thoughts about it? | 14:08 |
| ikhudoshyn | my head has, actually | 14:09 |
| isviridov | Any changes in table list response? | 14:09 |
| aostapenko | yes. It will additionally contain table name and id | 14:09 |
| ikhudoshyn | isviridov: i wouldn't add uuid to table list | 14:09 |
| *** charlesw has joined #magnetodb | 14:10 | |
| achudnovets | ikhudoshyn: why? | 14:10 |
| ikhudoshyn | uuid seems rather aux for me, with restricted usage | 14:11 |
| achudnovets | how user then be able to find table id then? | 14:11 |
| ikhudoshyn | describe table by name | 14:11 |
| ikhudoshyn | we'd allow describe by uuid as well | 14:11 |
| ikhudoshyn | i think we should keep table name as a primary id and add uuid only as aux id | 14:12 |
| aostapenko | create table response also will contain table id | 14:12 |
| ikhudoshyn | i expect uuid usage gonna be limited | 14:12 |
| isviridov | ikhudoshyn +1 for keeping list_tables response as is | 14:12 |
| isviridov | #link http://magnetodb.readthedocs.org/en/latest/list_tables.html | 14:13 |
| achudnovets | nova list shows IDs afaik | 14:13 |
| aostapenko | almost every OS components lists show IDs | 14:13 |
| ikhudoshyn | they use ID for regular node addressing | 14:13 |
| achudnovets | yep | 14:13 |
| ikhudoshyn | we'll use names | 14:13 |
| ikhudoshyn | look, table name is wellunderstood by al db users and devs | 14:14 |
| achudnovets | ikhudoshyn: you can use name in nova in most cases | 14:14 |
| ikhudoshyn | table id is used for some very specific cases | 14:14 |
| ikhudoshyn | achudnovets: the main consern is, we can't use both everywhere | 14:15 |
| ikhudoshyn | so we should stick to one | 14:15 |
| ikhudoshyn | and keep the other where we really need | 14:15 |
| achudnovets | i see. It can confuse openstack users... | 14:16 |
| charlesw | can we try uuid, if not found, then use name? | 14:16 |
| ikhudoshyn | hey, charlesw, glad to see you joined | 14:16 |
| ikhudoshyn | we'll do | 14:16 |
| aostapenko | charles: we are going to do so | 14:16 |
| charlesw | sorry morning traffic is bad | 14:16 |
| ikhudoshyn | but there are some places we wouldn't use ids | 14:16 |
| ikhudoshyn | like pagination and batches | 14:17 |
| ikhudoshyn | so for that cases i suggest to use names only | 14:17 |
| achudnovets | ikhudoshyn: so url patterns will be v1/{project_id}/data/tables/{UUID or table_name} ^ | 14:17 |
| achudnovets | ? | 14:17 |
| ikhudoshyn | yes | 14:17 |
| achudnovets | hm | 14:18 |
| aostapenko | achudnovets: yep | 14:18 |
| charlesw | what about give the choice to user. Add a property: idOrName | 14:18 |
| ikhudoshyn | charlesw: this wouldn't work for all cases | 14:18 |
| isviridov | charlesw do you mean teh URI? | 14:19 |
| charlesw | no, in the request body | 14:19 |
| isviridov | It means changing the other parts of API, but now we have an extending. | 14:20 |
| achudnovets | so how do you know that user provides UUID? | 14:20 |
| aostapenko | achudnovets: UUID has a priority | 14:20 |
| charlesw | or, can be in url as query parameter | 14:20 |
| aostapenko | first we are looking by uuid, if not found - by name | 14:21 |
| isviridov | charlesw from other hand the table name is more convinient for usage, that UUID | 14:21 |
| ikhudoshyn | charlesw: we dont use query params | 14:21 |
| achudnovets | it's ambiguous as for me | 14:21 |
| ikhudoshyn | achudnovets: i agree | 14:22 |
| ikhudoshyn | i'd actually forbid uuids in uris | 14:22 |
| ikhudoshyn | and only add ability to lookup by uuid | 14:22 |
| charlesw | @ikhudoshyn, we do have request parameter, such as limit in listTables | 14:22 |
| achudnovets | ikhudoshyn: I agree. Forbid uuid or name. And we can use name in query params in GET requests. It's common way | 14:23 |
| ikhudoshyn | charlesw: yes | 14:23 |
| ajayaa | ikhudoshyn, +1. I think we would be complicating things by adding uuid everywhere. | 14:23 |
| ikhudoshyn | there is special usecase where uuid is needed | 14:23 |
| ikhudoshyn | and there should be a way to find table by uuid | 14:24 |
| achudnovets | Then add filtering by UUID as filter in query params | 14:24 |
| charlesw | +1 for using name as default. If uuid is needed, give user the option to specify it in req body or req parameter | 14:24 |
| ikhudoshyn | or just add a separate method to find by id | 14:25 |
| charlesw | that can clutter the API | 14:26 |
| ikhudoshyn | and even more, we dont have a good uri for that) | 14:26 |
| isviridov | ikhudoshyn +1 | 14:26 |
| ajayaa | charlesw, We can add a filter to list table. | 14:26 |
| ikhudoshyn | ajayaa: it's not about listing but about describing | 14:27 |
| *** Chao_li has joined #magnetodb | 14:27 | |
| ikhudoshyn | like GET .../data/tables/{name} | 14:27 |
| isviridov | Let us summarize and go to the next topic | 14:27 |
| achudnovets | yep. Common way is to use id in query and be able to filter by name... | 14:27 |
| isviridov | #idea add lookup call by UUID | 14:28 |
| ikhudoshyn | it's a common way for OS but not for a DB | 14:28 |
| charlesw | achudnovets, is this you talking about: GET .../data/tables/{string}?byName=true? | 14:29 |
| isviridov | #idea add uuid in describe table attribute | 14:29 |
| achudnovets | no. I've speaking about /data/tables?uuid={string} or /data/tables?name={string} in list tables | 14:30 |
| aostapenko | I think that it will should be more openstack, than DB | 14:30 |
| aostapenko | And give the priority to UUID | 14:30 |
| ikhudoshyn | aostapenko: sorry i dont follow you | 14:31 |
| isviridov | #idea data/tables?uuid={string} | 14:31 |
| isviridov | achudnovets +1 | 14:31 |
| charlesw | achudnovets, that will have same url as listTables, not good | 14:31 |
| isviridov | achudnovets could you share it in specs? | 14:31 |
| achudnovets | It's for list tables | 14:31 |
| ikhudoshyn | charlesw: good point | 14:31 |
| isviridov | ikhudoshyn agree | 14:32 |
| achudnovets | for describe table I'd like to see /data/tables/{uuid} | 14:32 |
| achudnovets | by default | 14:32 |
| achudnovets | or /data/tables/{name} but not both | 14:32 |
| *** k4n0 has quit IRC | 14:33 | |
| ikhudoshyn | achudnovets: there'd be an issue with that | 14:33 |
| charlesw | what about GET .../data/tables/{string}?byName=true for describe by bane, GET .../data/tables/{string} for uuid | 14:33 |
| charlesw | bane -> name | 14:33 |
| ikhudoshyn | charlesw: maybe vice versa, | 14:34 |
| isviridov | achudnovets charlesw aostapenko ikhudoshyn it seems the topic is wider, let us continue offline | 14:34 |
| ikhudoshyn | ?byUUid=true | 14:34 |
| ajayaa | +1 for vice versa. | 14:34 |
| aostapenko | .../data/tables/{uuid or name} with uuid priority would be good | 14:34 |
| charlesw | depending on default behavior we like | 14:34 |
| achudnovets | Why we can't live it as it is :)? | 14:35 |
| ikhudoshyn | we need uuids sometimes | 14:35 |
| aostapenko | achudnovets: we need that lookup | 14:35 |
| ikhudoshyn | but for real life i like names, too | 14:35 |
| *** miqui_ has quit IRC | 14:36 | |
| isviridov | achudnovets we are intducing UUID in order to identify the table across openstack, but don't have teh way to lookup by uuid now | 14:36 |
| aostapenko | I started to like ?byUUid=true | 14:37 |
| aostapenko | and only in describe | 14:37 |
| isviridov | aostapenko what is url if so? | 14:38 |
| ikhudoshyn | isviridov: as it is now | 14:39 |
| achudnovets | guys how about update table then? | 14:39 |
| aostapenko | GET .../data/tables/{uuid}?byUUid=true | 14:39 |
| ikhudoshyn | achudnovets: as it is now | 14:39 |
| achudnovets | We'll have different urls for GET and PUT | 14:39 |
| ikhudoshyn | as we do now | 14:39 |
| isviridov | #idea extend describe_table with GET .../data/tables/{uuid}?byUUid=true | 14:40 |
| ikhudoshyn | we use /data/tables/ for put and /data/tables/{name} for get | 14:40 |
| ikhudoshyn | achudnovets: i assume put=create table | 14:40 |
| achudnovets | ikhudoshyn: disagree | 14:40 |
| achudnovets | we have similar urls for get and delete | 14:40 |
| ikhudoshyn | achudnovets: ? | 14:40 |
| ikhudoshyn | it's true | 14:41 |
| achudnovets | and we have no implementtion for update table now ) | 14:41 |
| achudnovets | so we have no url for it | 14:41 |
| ikhudoshyn | i thought POST is update | 14:41 |
| aostapenko | Lets end with lookup by uuid | 14:41 |
| isviridov | aostapenko do you have answers now? | 14:41 |
| aostapenko | and switch a topic | 14:41 |
| isviridov | aostapenko +1, what are your next steps? | 14:42 |
| aostapenko | I assume an answer is GET .../data/tables/{uuid}?byUUid=true | 14:42 |
| ikhudoshyn | #idea aostapenko to finish the spec and then vote) | 14:42 |
| aostapenko | so yes. I do | 14:42 |
| isviridov | Agreed | 14:42 |
| aostapenko | ikhudoshyn: ok | 14:42 |
| isviridov | #topic Add proposition to add rules to policy.json for service users(monitoring, admin API etc) and use domain scoped tokens. Depends on bp https://blueprints.launchpad.net/magnetodb/+spec/support-roles achudnovets | 14:42 |
| ikhudoshyn | in fact we could vote by merging the speec | 14:42 |
| isviridov | #link https://blueprints.launchpad.net/magnetodb/+spec/support-roles | 14:42 |
| isviridov | achudnovets stage is your | 14:43 |
| achudnovets | It's just an idea to add specific rules to policy.json For service users, like monitoring | 14:43 |
| ikhudoshyn | achudnovets: why not) | 14:44 |
| achudnovets | So we can add role "monitoring", assign this role to service user and login as this user with "doman" scope. | 14:45 |
| ikhudoshyn | achudnovets: +1 | 14:45 |
| isviridov | achudnovets sounds good, are you going to implement it? | 14:45 |
| achudnovets | Yep I can. I depens on https://blueprints.launchpad.net/magnetodb/+spec/support-roles | 14:46 |
| ajayaa | domain scope? | 14:46 |
| achudnovets | ajayaa: yes | 14:46 |
| achudnovets | I ->it's | 14:46 |
| ajayaa | Why exactly domain scope? | 14:46 |
| *** miqui_ has joined #magnetodb | 14:47 | |
| achudnovets | we have cases when user don't know tenant id's to make correct request | 14:47 |
| achudnovets | for example for monitoring API | 14:48 |
| ajayaa | http://{host}:8480/v1/{project_id}/monitoring/tables/table_name | 14:48 |
| ajayaa | I think in this url we have project_id. | 14:48 |
| achudnovets | yep. | 14:48 |
| ikhudoshyn | ajayaa: there is a refactoring in the line | 14:49 |
| achudnovets | to monitor all tables user need have some role in all projects | 14:49 |
| * isviridov greets miqui_ | 14:49 | |
| miqui_ | hey isviridov | 14:49 |
| ajayaa | Yes. That is not what we want. Agree. | 14:50 |
| ajayaa | I am sorry. I have not gone through refactoring work. Please add a spec when you implement this. | 14:50 |
| ajayaa | We can discuss it there. | 14:50 |
| isviridov | achudnovets ajayaa I think we will have cluster monitoring data eventually, not pinned to any specific tenant | 14:51 |
| charlesw | but even if you have domain scoped token, you still have to add the monitoring user to all projects, right? | 14:51 |
| ominakov | ajayaa, https://blueprints.launchpad.net/magnetodb/+spec/api-uri-format-change | 14:51 |
| ominakov | charlesw, no | 14:51 |
| achudnovets | charlesw: no, if projects are in one domain | 14:51 |
| isviridov | ajayaa it was discussed last meeting | 14:52 |
| charlesw | do you have a pointer? | 14:52 |
| charlesw | probably tied to certain version of keystone | 14:53 |
| ajayaa | charlesw, keystone v3. | 14:53 |
| isviridov | Can we use unscoped token, but check teh role only. f.e. monitoring_admin | 14:53 |
| ominakov | charlesw, with keystone v3 we can use one user with domain scoped token for operations in all tenants of this domain | 14:53 |
| ajayaa | isviridov, I am not sure there is an unscoped token with a role in it. | 14:53 |
| charlesw | no, unscoped token can only be used to deal with keystone | 14:54 |
| isviridov | ajayaa charlesw thx | 14:54 |
| charlesw | ominakov, have you tried it? | 14:54 |
| ajayaa | Who is going to use it? cluster monitoring api? | 14:55 |
| achudnovets | charlesw: are you speaking about domain scoped tokens? | 14:55 |
| charlesw | achudnovets, yes | 14:55 |
| ajayaa | The mdb service provider or the end user? | 14:55 |
| achudnovets | charlesw: I tried it on latest keystone. | 14:56 |
| charlesw | service provider I think | 14:56 |
| ominakov | charlesw, achudnovets, i also tried it | 14:56 |
| isviridov | charlesw +1, service provider | 14:56 |
| ajayaa | Then why limit it to a projects in a domain? | 14:57 |
| ajayaa | The service provider should get stat for tables in all the projects. | 14:57 |
| charlesw | cause we don't want to add monitoring user to every project | 14:58 |
| isviridov | The problems sounds like - give a service provider a possibility to check mdb usage by specific tenant, all tenants, overall usage and statistics | 14:58 |
| ominakov | ajayaa, we have all our projects (users of mdb) in one domain | 14:58 |
| isviridov | ominakov it is specific case and can be different | 14:59 |
| ajayaa | isviridov +1 | 14:59 |
| isviridov | Guys we have 1 min left, I think we have to dig it deeper, the thing we see is auth via keystone is a pain for service providers. | 14:59 |
| ajayaa | charlesw, We don't have to. | 15:00 |
| ajayaa | He can have the said role in any of the project and use that token. | 15:00 |
| charlesw | but only to the same domain | 15:00 |
| isviridov | Meeting is over, we can continue discussion | 15:00 |
| isviridov | #endmeeting | 15:01 |
| openstack | Meeting ended Thu Dec 4 15:01:03 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:01 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.html | 15:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.txt | 15:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/magnetodb/2014/magnetodb.2014-12-04-14.00.log.html | 15:01 |
| achudnovets | So to make it simple, the idea is to implement domain scoped tokens support. For service users or for others.. | 15:01 |
| charlesw | do we have to implement anything? Keystone v3 already has it | 15:01 |
| achudnovets | the "implementation" is only adding specific rules to policy.json :) | 15:02 |
| charlesw | got it, thx | 15:02 |
| ajayaa | achudnovets, more precisely, support domain scoped token in cluster monitoring api? | 15:03 |
| *** Chao_li has quit IRC | 15:04 | |
| achudnovets | ajayaa: I don't know now. I need to check how we are going to change monitoring api. Think I missed a lot :) | 15:06 |
| ajayaa | Anyway I wanted to update everyone on nova's auth model. The project_id in the url and project_id in token should match. | 15:06 |
| ajayaa | Otherwise it gives 400. | 15:06 |
| ajayaa | So, you should have a role in every project in which you want to operate. | 15:07 |
| ajayaa | achudnovets, :) | 15:07 |
| isviridov | ajayaa thank you for update | 15:08 |
| ajayaa | I think we could follow the same model. My earlier motivation for not enforcing this was to not have this restriction. | 15:08 |
| ajayaa | But then this requires another call to keystone or fetching a list of projects and caching it. | 15:09 |
| ajayaa | So in the spirit of not complicating things we could go with the restriction. | 15:09 |
| ajayaa | isviridov, aostapenko, What do you think? | 15:10 |
| isviridov | Seems I've mixed topics. Why do we need fetching all projects? | 15:10 |
| isviridov | Sorry | 15:11 |
| achudnovets | ajayaa: I thought default auth is: user has correct role for project_id from url | 15:11 |
| aostapenko | ajayaa: I think we can check if tokens tenant is equal to tenant from url | 15:12 |
| ajayaa | isviridov, Just a bit of background. RIght now there is a restriction in mdb which matched project_id in url and project_id in the token. | 15:12 |
| ajayaa | aostapenko, +1 exactly. | 15:13 |
| * isviridov is following ajayaa | 15:13 | |
| achudnovets | ajayaa: actually now we have a stub for auth :) | 15:14 |
| ajayaa | I wanted to do away with that restriction and control everything from policy.json. But then we risk creating keyspaces corresponding to non-existent projects in keystone unless we check for its existence. | 15:14 |
| ajayaa | isviridov, I hope it is clear. | 15:15 |
| isviridov | ajayaa yes, it is clear now. | 15:15 |
| ajayaa | achudnovets, That's nice. | 15:15 |
| isviridov | So, we do add this enforcement and no additiona requests to keystone needed | 15:16 |
| ajayaa | Yes. | 15:16 |
| isviridov | Cool, thx | 15:16 |
| achudnovets | I think we should check if project_id is the same AND user has correct role in this project | 15:16 |
| ajayaa | achudnovets, We will be doing that. | 15:16 |
| ajayaa | The question was to whether we should enforce url's project_id=token's project_id. | 15:17 |
| charlesw | achudnovets, ominakov, do you have the scripts to demo domain scoped token can be used to access any projects in the domain? | 15:17 |
| achudnovets | charlesw: I have | 15:17 |
| charlesw | if you can share, it will be great | 15:18 |
| achudnovets | sure | 15:18 |
| ajayaa | achudnovets, But only in keystone, not in other components I guess. | 15:18 |
| ajayaa | isviridov, Do you have some time to discuss ceilometer integration? | 15:19 |
| *** ajayaa has quit IRC | 15:21 | |
| charlesw | guys, pls take a look at: https://review.openstack.org/138950 (request metrics bp). Would love to hear back from you. | 15:21 |
| isviridov | charlesw will do | 15:22 |
| charlesw | isviridov, thx | 15:22 |
| isviridov | ajayaa yes :) | 15:23 |
| *** jeromatron has joined #magnetodb | 15:23 | |
| isviridov | jeromatron hello | 15:24 |
| jeromatron | Hi, how are things going? | 15:24 |
| isviridov | All right, thank you | 15:25 |
| isviridov | You know we are building own custom seconrady index and we would love to have your eyes on it. | 15:25 |
| isviridov | If you have time here it is https://review.openstack.org/#/c/107500/ | 15:26 |
| isviridov | miqui miqui_ how it is going? | 15:28 |
| *** isviridov is now known as isviridov_break | 15:30 | |
| miqui_ | hi isviridov_break... am doing ok...busy as heck... | 15:33 |
| miqui_ | ...andin between stuff....learning magnetodb :) | 15:34 |
| openstackgerrit | Andrei V. Ostapenko proposed stackforge/magnetodb-specs: Adds table uuid in uri specification https://review.openstack.org/137336 | 15:34 |
| charlesw | miqui_, we are in same TZ, feel free to ping me while isviridov is unavailable | 15:36 |
| miqui_ | ...awesome... thanks... | 15:37 |
| *** avinogradov has quit IRC | 15:46 | |
| *** jeromatron has quit IRC | 16:04 | |
| *** miqui__ has joined #magnetodb | 16:15 | |
| *** jeromatron has joined #magnetodb | 16:15 | |
| *** miqui_ has quit IRC | 16:18 | |
| *** ajayaa has joined #magnetodb | 16:24 | |
| *** jeromatron has quit IRC | 16:32 | |
| *** romainh has left #magnetodb | 16:38 | |
| *** jeromatron has joined #magnetodb | 16:47 | |
| *** jeromatr_ has joined #magnetodb | 16:55 | |
| openstackgerrit | Charles Wang proposed stackforge/magnetodb-specs: Add request metrics speccification https://review.openstack.org/138950 | 17:02 |
| *** jeromatron has quit IRC | 17:12 | |
| *** jeromatr_ has quit IRC | 17:24 | |
| *** openstackgerrit has quit IRC | 18:50 | |
| *** openstackgerrit has joined #magnetodb | 18:50 | |
| *** ajayaa has quit IRC | 18:59 | |
| *** rushiagr is now known as rushiagr_away | 19:38 | |
| *** jeromatron has joined #magnetodb | 20:00 | |
| *** openstackgerrit has quit IRC | 20:04 | |
| *** openstackgerrit has joined #magnetodb | 20:04 | |
| *** rushiagr_away is now known as rushiagr | 21:22 | |
| *** denis_makogon_ has joined #magnetodb | 21:51 | |
| *** achuprin_ has quit IRC | 22:25 | |
| *** nunosantos has quit IRC | 22:37 | |
| *** jeromatron has quit IRC | 22:37 | |
| *** charlesw has quit IRC | 22:49 | |
| *** miqui__ has quit IRC | 22:54 | |
| *** Jon___ has quit IRC | 22:56 | |
| *** denis_makogon_ has quit IRC | 23:12 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!