Open Stack

Dear Vishvananda,

Sorry for very late reply. I was stupid not to follow your reply (i had messed it some how).

Actually, i am confused after seeing your mail. In the last two weeks, i was doing some testing (creating use cases) on Keystone and Nova.

Part 1:  Delegating rights

I had made the following observations using Keystone V3

1. RBAC were not working in Keystone V2 (it was only working in V3)
2. In V3, I could create a role (like 'listRole') and created a user in a tenant with this role
3. I had changed the RBAC rules in policy.json file of keystone to allowed a user with the 'listRole' in addition to admin, to run the "list_domains", "list_projects" and "list_users" operations
   (earlier this operations can only be run by admin or we can say super-user)
4. These settings were successful and working perfectly fine.

What my point is here, by playing with RBAC with V3 APIs of keystone, i could delegate rights to users.

So, i thought the same can be achieved in any other service (like nova).
For example, i thought in nova also i can create a role add change the policy.json file to allow him to do the necessary operations like list, update etc..

I could not do this check, because i couldn't able to run Nova with V3 successfully and also could not find the Nova V3 APIs.

But one thing i guess is missing here (even in keystone) is that, if we allow a normal user with a role to do certain operations, then he/she can do those operations in another domain or another project, in which he does not belong to.
So, i guess this can checked in the code. Lets use RBAC rules to check whether a person can run that query or not. Once RBAC says it is allowed, we can check whether an admin/super-user is running or a normal user is running that query.
If the user is admin, he can request for anything. If the user is a normal user, then we can check whether he is asking only for his domain or his project. If so, then only allow otherwise raise an error.

Part 2: Quotas

I would also like to discuss with you about quotas.

As you know, the current quota system is de-centralized and the driver available in nova is "DbQuotaDriver", which allows to set quotas for a tenant and users in the tenant.
I could manage the quota driver to point to a new driver called "DomainQuotaDriver" (from Tiago Martins and team from HP) in nova code. I had built a test case in which i checked that a tenant quota cannot be greater than the domain quota in which the tenant is registered.Even, the sum of all tenant quotas cannot exceed their domain quota. In this, what is missing is the API's to operate the quotas for domains. I thought of creating these API's in V2 (as i could not find V3 APIs in nova). So, a new level called domain will be added to existing quota APIs. For example, the current API "v2/{tenant_id}/os-quota-sets<http://docs.openstack.org/api/openstack-compute/2/content/GET_os-quota-sets-v2_showQuota_v2__tenant_id__os-quota-sets_ext-os-quota-sets.html>" allows to see the quotas for a tenant. Probably, this can be changed to "v2/{domain_id}/{tenant_id}/os-quota-sets<http://docs.openstack.org/api/openstack-compute/2/content/GET_os-quota-sets-v2_showQuota_v2__tenant_id__os-quota-sets_ext-os-quota-sets.html>" to see the quotas for a tenant in a domain.

I am currently trying to understand the nova-api code to see how and API mapping is done (through routes) and how an API calling is actually leading to a python function being called. Once i complete this, i am thinking of about these API's. Ideally implementation the extension of domain quotas in V3 APIs would have been good. But as i said i could not find any documentation about the Nova V3 APIs


I feel once we have Part 1 and Part 2, then quota delegation is not a big task. Because with RBAC rules, we can allow a user lets say with "tenant admin" role, can set the quotas for all the users in that tenant.


Please post your comments on this. Here at CERN we want to contribute to the quota management (earlier thought of centralized quota, but currently going with de-centralized quota with openstack services keeping the quota data).
I will wait for your comments to guide us or tell us how we can contribute..

Thanks & Regards,
Vinod Kumar Boppanna



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140129/ca092135/attachment.html>