[openstack-dev] Havana Release V3 Extensions and new features to quota
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-setshttp://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-setshttp://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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Havana Release V3 Extensions and new features to quota
On Jan 29, 2014, at 3:55 AM, Vinod Kumar Boppanna
vinod.kumar.boppa...@cern.ch wrote:
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.
This idea is great in principle, but “asking only for his domain or his project
doesn’t make any sense in this case”. In nova objects are explicitly owned by a
project. There is no way to determine of an object is part of a domain, so
roles in that sense are non-functional. This is true across projects and is
something tht needs to be addressed.
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 allows to see the quotas for a tenant.
Probably, this can be changed to v2/{domain_id}/{tenant_id}/os-quota-sets
to see the quotas for a tenant in a domain.
Again this makes sense in principle. We do have the domain in the request
context from keystone. Unfortunately, once again there is no mapping of domain
to object so there is no way to count the existing objects to determine how
much has already been used.
If you can make the Hierarchical Ownership meeting tomorrow we will discuss
adressing these and other issues so that we can at the very least have a
prototype solution.
Vish
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
Re: [openstack-dev] Havana Release V3 Extensions and new features to quota
Hi Vinod, Sorry for the top post, but there is a lot that needs to be done across projects to make the idea of domains and trees actually work. One of the issues which you mention below is the idea of quotas. I was just having a discussion with some folks in IRC about this very issue, and there are quite a few people who would like to help with this. I’m going to send out another email to the list entitled “Hierarchicical Multitenancy Discussion” in a bit on this topic. Vish On Jan 20, 2014, at 3:17 AM, Vinod Kumar Boppanna vinod.kumar.boppa...@cern.ch wrote: Hi, My name is Vinod Kumar Boppanna and I was testing the quota part in the OpenStack Havana Release. I had installed the Havana Release in a single VM through RDO process. During testing, i used the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v2.0/ Because of this, the nova is using the following v2 attributes for the quotas compute_extension:quotas:show: , compute_extension:quotas:update: rule:admin_api, compute_extension:quotas:delete: rule:admin_api, But there are other quota attributes available for v3 and they are compute_extension:v3:os-quota-sets:discoverable: , compute_extension:v3:os-quota-sets:show: , compute_extension:v3:os-quota-sets:update: rule:admin_api, compute_extension:v3:os-quota-sets:delete: rule:admin_api, compute_extension:v3:os-quota-sets:detail: rule:admin_api, My question is how can i use the V3 extensions. I mean, whether i can use them by changing the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v3.0/ (but this didn't worked). I also have a doubt whether RDO process installed the Havana setup with V3 extensions or just V2 extensions? I could test all the existing quota features with respect to tenant and the users in a tenant. During this, i had observed the following things 1. Weak Notifications - Let’s say that a user is added as a member of a project and he had created an instance in that project. When he logs in to the dashboard he can see that an instance has been created by him. Now, the administrator removed his membership from the “project”. Now when user logs in, he will not be able to see the instance that he created earlier. But the instance still exists and the user can log onto it. But if administrator adds him back to the project, then the user is able to see again the same instance. 2. By default the policy.json file allows any user in a project to destroy an instance created by another user in the same project 3. I couldn't find a link or page in the dashboard where i can set the quota limits of a user in a project. I could do for a project, but not for a User. I did set the quota limits for the user using nova commands. 4. When i see instances that have created by users in a project, it does not show who has created that instance. For eg: if a project has 2 users and each user created 1 instance of VM each, then in the Instances link, the dashboard show both the instances with their name and details. But it does now show who has created which VM. 5. When a VM is created, it normally allows SSH login using the key pair generated by the user. But the console link provided in the dashboard only allows login through password. So, i have to atleast once login to the VM through command line using the key, sets the root password (because during the VM creation, i am not asked to enter the root password) and then use the console provided in the dashboard. We also had a short discussion here (at CERN) to take the quota features further. Among these features, the first one we would like to have is Define roles like Admin (which is already there), Domain Admin and Project Admin. The Admin can define different domains in the cloud and also assign a person as Domain Admin to each domain respectively. Also, the Admin will define quota to each Domain. The Domain Admin role for a person in a Domain allows him/her to define the Projects/Tenants in that domain and also define a person as Project Admin to each project in that domain respectively. This person will also define Quota for each project with the condition that the sum of quota limits of all projects should be less than or equal to its domain quota limits. The Project Admin can add users to each project and also define quota for each user respectively. We are thinking of first having this sort of tree hierarchy where the parent can manage all the things beneath them. I think for this, we need to have the following things in OpenStack 1. Allow to define roles (this is already there) 2. Define the meaning of these roles in the policy.json file of nova 3. Need to add little bit of code to understand this hierarchy and allow the functionalities explained above. Once we have this, we can then think of quota delegation. Any comments, please let me know... Regards, Vinod Kumar
Re: [openstack-dev] Havana Release V3 Extensions and new features to quota
Hi Vinod, On Mon, Jan 20, 2014 at 9:47 PM, Vinod Kumar Boppanna vinod.kumar.boppa...@cern.ch wrote: Hi, My name is Vinod Kumar Boppanna and I was testing the quota part in the OpenStack Havana Release. I had installed the Havana Release in a single VM through RDO process. During testing, i used the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v2.0/ Because of this, the nova is using the following v2 attributes for the quotas compute_extension:quotas:show: , compute_extension:quotas:update: rule:admin_api, compute_extension:quotas:delete: rule:admin_api, But there are other quota attributes available for v3 and they are compute_extension:v3:os-quota-sets:discoverable: , compute_extension:v3:os-quota-sets:show: , compute_extension:v3:os-quota-sets:update: rule:admin_api, compute_extension:v3:os-quota-sets:delete: rule:admin_api, compute_extension:v3:os-quota-sets:detail: rule:admin_api, My question is how can i use the V3 extensions. I mean, whether i can use them by changing the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v3.0/ (but this didn't worked). I also have a doubt whether RDO process installed the Havana setup with V3 extensions or just V2 extensions? The V3 API in Havana is experimental and is disabled by default but you can enabled it by modifying your nova.conf file. There is a section osapi_v3 which has config variable of enabled which if set to True will turn on the V3 API. Note that in Havana there is no python-novaclient support for the V3 API so you will have to access the REST API directly. However, the python-novaclient support for the V3 API in the icehouse development is almost complete. I could test all the existing quota features with respect to tenant and the users in a tenant. During this, i had observed the following things 1. Weak Notifications - Let’s say that a user is added as a member of a project and he had created an instance in that project. When he logs in to the dashboard he can see that an instance has been created by him. Now, the administrator removed his membership from the “project”. Now when user logs in, he will not be able to see the instance that he created earlier. But the instance still exists and the user can log onto it. But if administrator adds him back to the project, then the user is able to see again the same instance. 2. By default the policy.json file allows any user in a project to destroy an instance created by another user in the same project 3. I couldn't find a link or page in the dashboard where i can set the quota limits of a user in a project. I could do for a project, but not for a User. I did set the quota limits for the user using nova commands. 4. When i see instances that have created by users in a project, it does not show who has created that instance. For eg: if a project has 2 users and each user created 1 instance of VM each, then in theInstances link, the dashboard show both the instances with their nameand details. But it does now show who has created which VM. The API does return this information, both in a general instance listing as well as a detailed listing or query about a specific instance. On the command line if you do a nova show instance_uuid it will display the user_id who created the instance. 5. When a VM is created, it normally allows SSH login using the key pair generated by the user. But the console link provided in the dashboard only allows login through password. So, i have to atleast once login to the VM through command line using the key, sets the root password (because during the VM creation, i am not asked to enter the root password) and then use the console provided in the dashboard. You can send an extra parameter during the instance creation request (admin_pass in V2, admin_password in v3) but it is only supported by Xen I think. Otherwise you can look at using something like the server_password extension and/or setting it using cloud-init. We also had a short discussion here (at CERN) to take the quota features further. Among these features, the first one we would like to have is Define roles like Admin (which is already there), Domain Admin and Project Admin. The Admin can define different domains in the cloud and also assign a person as Domain Admin to each domain respectively. Also, the Admin will define quota to each Domain. The Domain Admin role for a person in a Domain allows him/her to define the Projects/Tenants in that domain and also define a person as Project Admin to each project in that domain respectively. This person will also define Quota for each project with the condition that the sum of quota limits of all projects should be less than or equal to its domain quota limits. The Project Admin can add users to each project and also define quota for each user respectively. We are thinking of first having this sort of tree
[openstack-dev] Havana Release V3 Extensions and new features to quota
Hi, My name is Vinod Kumar Boppanna and I was testing the quota part in the OpenStack Havana Release. I had installed the Havana Release in a single VM through RDO process. During testing, i used the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v2.0/ Because of this, the nova is using the following v2 attributes for the quotas compute_extension:quotas:show: , compute_extension:quotas:update: rule:admin_api, compute_extension:quotas:delete: rule:admin_api, But there are other quota attributes available for v3 and they are compute_extension:v3:os-quota-sets:discoverable: , compute_extension:v3:os-quota-sets:show: , compute_extension:v3:os-quota-sets:update: rule:admin_api, compute_extension:v3:os-quota-sets:delete: rule:admin_api, compute_extension:v3:os-quota-sets:detail: rule:admin_api, My question is how can i use the V3 extensions. I mean, whether i can use them by changing the AUTH_URL as OS_AUTH_URL=http://ip_address:35357/v3.0/ (but this didn't worked). I also have a doubt whether RDO process installed the Havana setup with V3 extensions or just V2 extensions? I could test all the existing quota features with respect to tenant and the users in a tenant. During this, i had observed the following things 1. Weak Notifications - Let’s say that a user is added as a member of a project and he had created an instance in that project. When he logs in to the dashboard he can see that an instance has been created by him. Now, the administrator removed his membership from the “project”. Now when user logs in, he will not be able to see the instance that he created earlier. But the instance still exists and the user can log onto it. But if administrator adds him back to the project, then the user is able to see again the same instance. 2. By default the policy.json file allows any user in a project to destroy an instance created by another user in the same project 3. I couldn't find a link or page in the dashboard where i can set the quota limits of a user in a project. I could do for a project, but not for a User. I did set the quota limits for the user using nova commands. 4. When i see instances that have created by users in a project, it does not show who has created that instance. For eg: if a project has 2 users and each user created 1 instance of VM each, then in the Instances link, the dashboard show both the instances with their name and details. But it does now show who has created which VM. 5. When a VM is created, it normally allows SSH login using the key pair generated by the user. But the console link provided in the dashboard only allows login through password. So, i have to atleast once login to the VM through command line using the key, sets the root password (because during the VM creation, i am not asked to enter the root password) and then use the console provided in the dashboard. We also had a short discussion here (at CERN) to take the quota features further. Among these features, the first one we would like to have is Define roles like Admin (which is already there), Domain Admin and Project Admin. The Admin can define different domains in the cloud and also assign a person as Domain Admin to each domain respectively. Also, the Admin will define quota to each Domain. The Domain Admin role for a person in a Domain allows him/her to define the Projects/Tenants in that domain and also define a person as Project Admin to each project in that domain respectively. This person will also define Quota for each project with the condition that the sum of quota limits of all projects should be less than or equal to its domain quota limits. The Project Admin can add users to each project and also define quota for each user respectively. We are thinking of first having this sort of tree hierarchy where the parent can manage all the things beneath them. I think for this, we need to have the following things in OpenStack 1. Allow to define roles (this is already there) 2. Define the meaning of these roles in the policy.json file of nova 3. Need to add little bit of code to understand this hierarchy and allow the functionalities explained above. Once we have this, we can then think of quota delegation. Any comments, please let me know... Regards, Vinod Kumar Boppanna ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
