OpenStack - User contributions [en]

APIs for Domain Quota Driver

2014-04-11T08:58:50Z

Vinod kumar boppanna: /* Implementation */

== Introduction ==

The existing DbQuotaDriver in Nova allows to set the Quotas at Project/Tenant and User Level. But there is a need to enforce the quotas at Domain Level as well. A new driver called "Domain Quota Driver" is available to enforce domain quotas in Nova. To use this driver, a new set of APIs are required for CRUD operations on quotas at domain, project and user level.

== Quotas in Nova==
Currently, OpenStack services make usage of quotas to limit the resources for a project or for a user.
For example, the “Instances” quota represents the number of instances that can be created in a project or by a user. Through Domain Quota Driver, the same options for Quotas are available in the context of domain. To read more about Domain Quota Driver and see the available options for quotas, check https://wiki.openstack.org/wiki/DomainQuotaDriver

= Implementation =

=== V2 APIs ===
Please check the following table for the APIs to manage Quotas for Domain, Project and User respectively. These APIs can be used by admin (i.e with role admin) to get the quota limits of any domain/project/user. A non-admin user can only use these APIs to see the quotas of a domain to which he/she belongs or of a project in which he/she is a member. In addition the non-admin user can see his/her own quota limits. To make this possible, Keystone V3 auth tokens needs to be used. The context provided by the token has domain_id, project_id and user_id respectively.

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v2/{tenant_id}/os-domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v2/{tenant_id}/os-domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v2/{tenant_id}/os-domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v2/{tenant_id}/os-domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v2/{tenant_id}/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

=== V3 APIs ===

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v3/os-domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v3/os-domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v3/os-domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v3/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v3/os-domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v3/os-domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v3/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v3/os-domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v3/os-domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v3/os-domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

POC for QuotaManagement

2014-04-06T16:32:39Z

Vinod kumar boppanna: /* POC Demo code */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "roles". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"context_is_admin": "role:admin"
"project_admin": "role:project-admin and project_id:%(project_id)s"
"admin_or_project_admin": "rule: context_is_admin or rule:project_admin"

This means that the user satisfies one of the following condition 
*Cloud Admin
*check that user has a project-admin role using the the context field "roles" and has the selected project_id scope

The policy rules for the quota extension can be

"member": "role:member and project_id:%(project_id)s" (means that user has role member in the project)
"admin_or_project_admin_or_member": "rule:admin_or_project_admin or rule:member"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/4147173a415108e9496d6265522ea57bec5d1409

== Concerns ==
* The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this.

APIs for Domain Quota Driver

2014-03-21T12:30:43Z

Vinod kumar boppanna: /* APIs */

POC for QuotaManagement

2014-03-20T12:31:42Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "roles". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"context_is_admin": "role:admin"
"project_admin": "role:project-admin and project_id:%(project_id)s"
"admin_or_project_admin": "rule: context_is_admin or rule:project_admin"

This means that the user satisfies one of the following condition 
*Cloud Admin
*check that user has a project-admin role using the the context field "roles" and has the selected project_id scope

The policy rules for the quota extension can be

"member": "role:member and project_id:%(project_id)s" (means that user has role member in the project)
"admin_or_project_admin_or_member": "rule:admin_or_project_admin or rule:member"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this.

POC for QuotaManagement

2014-03-20T12:16:53Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)s"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this.

POC for QuotaManagement

2014-03-20T12:03:36Z

Vinod kumar boppanna: /* Concerns */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this.

POC for QuotaManagement

2014-03-20T12:00:50Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T12:00:30Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" in the keystone scope has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T11:56:50Z

Vinod kumar boppanna: /* Authentication */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA4 
<ins>Roles (find role at each project level upto the head node)</ins> 
* member

===== Example 6 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T11:54:57Z

Vinod kumar boppanna: /* Authentication */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T11:51:27Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except admin and project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T11:46:20Z

Vinod kumar boppanna: /* Authentication */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project to the top i.e till the head node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-03-20T11:44:14Z

Vinod kumar boppanna: /* Authentication */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the head node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the head node)</ins> 
* admin

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the head node) 
* admin

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member

===== Example 4 =====
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1.ProjA3 
<ins>Roles (find role at each project level upto the head node)</ins> 
* project-admin, member
̽Noteː
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.

===== Example 5 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

APIs for Domain Quota Driver

2014-02-18T18:04:23Z

Vinod kumar boppanna: /* Introduction */

APIs for Domain Quota Driver

2014-02-18T18:04:05Z

Vinod kumar boppanna: /* Implementation */

APIs for Domain Quota Driver

2014-02-18T12:45:12Z

Vinod kumar boppanna: /* Nova Commands */

== Introduction ==

The existing DbQuotaDriver in Nova allows to set the Quotas at Project/Tenant and User Level. But there is a need to enforce the quotas at Domain Level as well. A new driver called "Domain Quota Driver" is available to enforce domain quotas in Nova. To use this driver, a new set of APIs and Command Line tools are required for CRUD operations on quotas at domain, project and user level.

== Quotas in Nova==
Currently, OpenStack services make usage of quotas to limit the resources for a project or for a user.
For example, the “Instances” quota represents the number of instances that can be created in a project or by a user. Through Domain Quota Driver, the same options for Quotas are available in the context of domain. To read more about Domain Quota Driver and see the available options for quotas, check https://wiki.openstack.org/wiki/DomainQuotaDriver

= Implementation =

=== APIs ===
Please check the following table for the APIs to manage Quotas for Domain, Project and User respectively. These APIs can be used by admin (i.e with role admin) to get the quota limits of any domain/project/user. A non-admin user can only use these APIs to see the quotas of a domain to which he/she belongs or of a project in which he/she is a member. In addition the non-admin user can see his/her own quota limits. To make this possible, Keystone V3 auth tokens needs to be used. The context provided by the token has domain_id, project_id and user_id respectively.

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

=== Nova Commands ===

Following commands have been added to nova for Domain Quota Management

'''$> nova domain-quota-show'''

List the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to list the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to list the quotas for.
--user <user-id> ID of user to list the quotas for.

'''$> nova domain-quota-defaults'''

List the default quotas for a domain.

Positional arguments:
<domain-id> ID of domain to list the default quotas for.

'''$> nova domain-quota-delete'''

Delete quota for a domain/tenant/user so their quota will Revert back to
default.

Positional arguments:
<domain-id> ID of domain to delete quota for.

Optional arguments:
--tenant <tenant-id> ID of tenant to delete quota for.
--user <user-id> ID of user to delete quota for.

'''$> nova domain-quota-update'''

Update the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to set the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to set the quotas for.
--user <user-id> ID of user to set the quotas for.
--instances <instances>
New value for the "instances" quota.
--cores <cores> New value for the "cores" quota.
--ram <ram> New value for the "ram" quota.
--floating-ips <floating-ips>
New value for the "floating-ips" quota.
--fixed-ips <fixed-ips>
New value for the "fixed-ips" quota.
--metadata-items <metadata-items>
New value for the "metadata-items" quota.
--injected-files <injected-files>
New value for the "injected-files" quota.
--injected-file-content-bytes <injected-file-content-bytes>
New value for the "injected-file-content-bytes" quota.
--injected-file-path-bytes <injected-file-path-bytes>
New value for the "injected-file-path-bytes" quota.
--key-pairs <key-pairs>
New value for the "key-pairs" quota.
--security-groups <security-groups>
New value for the "security-groups" quota.
--security-group-rules <security-group-rules>
New value for the "security-group-rules" quota.

APIs for Domain Quota Driver

2014-02-18T12:44:43Z

Vinod kumar boppanna: /* Implementation */

== Introduction ==

The existing DbQuotaDriver in Nova allows to set the Quotas at Project/Tenant and User Level. But there is a need to enforce the quotas at Domain Level as well. A new driver called "Domain Quota Driver" is available to enforce domain quotas in Nova. To use this driver, a new set of APIs and Command Line tools are required for CRUD operations on quotas at domain, project and user level.

== Quotas in Nova==
Currently, OpenStack services make usage of quotas to limit the resources for a project or for a user.
For example, the “Instances” quota represents the number of instances that can be created in a project or by a user. Through Domain Quota Driver, the same options for Quotas are available in the context of domain. To read more about Domain Quota Driver and see the available options for quotas, check https://wiki.openstack.org/wiki/DomainQuotaDriver

= Implementation =

=== APIs ===
Please check the following table for the APIs to manage Quotas for Domain, Project and User respectively. These APIs can be used by admin (i.e with role admin) to get the quota limits of any domain/project/user. A non-admin user can only use these APIs to see the quotas of a domain to which he/she belongs or of a project in which he/she is a member. In addition the non-admin user can see his/her own quota limits. To make this possible, Keystone V3 auth tokens needs to be used. The context provided by the token has domain_id, project_id and user_id respectively.

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

=== Nova Commands ===

Following commands have been added to nova for Domain Quota Management

'''$> nova domain-quota-show'''

List the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to list the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to list the quotas for.
--user <user-id> ID of user to list the quotas for.

'''$> nova domain-quota-defaults'''
List the default quotas for a domain.

Positional arguments:
<domain-id> ID of domain to list the default quotas for.

'''$> nova domain-quota-delete'''
Delete quota for a domain/tenant/user so their quota will Revert back to
default.

Positional arguments:
<domain-id> ID of domain to delete quota for.

Optional arguments:
--tenant <tenant-id> ID of tenant to delete quota for.
--user <user-id> ID of user to delete quota for.

'''$> nova domain-quota-update'''
Update the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to set the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to set the quotas for.
--user <user-id> ID of user to set the quotas for.
--instances <instances>
New value for the "instances" quota.
--cores <cores> New value for the "cores" quota.
--ram <ram> New value for the "ram" quota.
--floating-ips <floating-ips>
New value for the "floating-ips" quota.
--fixed-ips <fixed-ips>
New value for the "fixed-ips" quota.
--metadata-items <metadata-items>
New value for the "metadata-items" quota.
--injected-files <injected-files>
New value for the "injected-files" quota.
--injected-file-content-bytes <injected-file-content-bytes>
New value for the "injected-file-content-bytes" quota.
--injected-file-path-bytes <injected-file-path-bytes>
New value for the "injected-file-path-bytes" quota.
--key-pairs <key-pairs>
New value for the "key-pairs" quota.
--security-groups <security-groups>
New value for the "security-groups" quota.
--security-group-rules <security-group-rules>
New value for the "security-group-rules" quota.

APIs for Domain Quota Driver

2014-02-18T12:44:28Z

Vinod kumar boppanna: /* Implementation */

== Introduction ==

The existing DbQuotaDriver in Nova allows to set the Quotas at Project/Tenant and User Level. But there is a need to enforce the quotas at Domain Level as well. A new driver called "Domain Quota Driver" is available to enforce domain quotas in Nova. To use this driver, a new set of APIs and Command Line tools are required for CRUD operations on quotas at domain, project and user level.

== Quotas in Nova==
Currently, OpenStack services make usage of quotas to limit the resources for a project or for a user.
For example, the “Instances” quota represents the number of instances that can be created in a project or by a user. Through Domain Quota Driver, the same options for Quotas are available in the context of domain. To read more about Domain Quota Driver and see the available options for quotas, check https://wiki.openstack.org/wiki/DomainQuotaDriver

= Implementation =

=== APIs ====
Please check the following table for the APIs to manage Quotas for Domain, Project and User respectively. These APIs can be used by admin (i.e with role admin) to get the quota limits of any domain/project/user. A non-admin user can only use these APIs to see the quotas of a domain to which he/she belongs or of a project in which he/she is a member. In addition the non-admin user can see his/her own quota limits. To make this possible, Keystone V3 auth tokens needs to be used. The context provided by the token has domain_id, project_id and user_id respectively.

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

=== Nova Commands ===

Following commands have been added to nova for Domain Quota Management

'''$> nova domain-quota-show'''

List the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to list the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to list the quotas for.
--user <user-id> ID of user to list the quotas for.

'''$> nova domain-quota-defaults'''
List the default quotas for a domain.

Positional arguments:
<domain-id> ID of domain to list the default quotas for.

'''$> nova domain-quota-delete'''
Delete quota for a domain/tenant/user so their quota will Revert back to
default.

Positional arguments:
<domain-id> ID of domain to delete quota for.

Optional arguments:
--tenant <tenant-id> ID of tenant to delete quota for.
--user <user-id> ID of user to delete quota for.

'''$> nova domain-quota-update'''
Update the quotas for a domain/tenant/user.

Positional arguments:
<domain-id> ID of domain to set the quotas for.

Optional arguments:
--tenant <tenant-id> ID of tenant to set the quotas for.
--user <user-id> ID of user to set the quotas for.
--instances <instances>
New value for the "instances" quota.
--cores <cores> New value for the "cores" quota.
--ram <ram> New value for the "ram" quota.
--floating-ips <floating-ips>
New value for the "floating-ips" quota.
--fixed-ips <fixed-ips>
New value for the "fixed-ips" quota.
--metadata-items <metadata-items>
New value for the "metadata-items" quota.
--injected-files <injected-files>
New value for the "injected-files" quota.
--injected-file-content-bytes <injected-file-content-bytes>
New value for the "injected-file-content-bytes" quota.
--injected-file-path-bytes <injected-file-path-bytes>
New value for the "injected-file-path-bytes" quota.
--key-pairs <key-pairs>
New value for the "key-pairs" quota.
--security-groups <security-groups>
New value for the "security-groups" quota.
--security-group-rules <security-group-rules>
New value for the "security-group-rules" quota.

APIs for Domain Quota Driver

2014-02-18T12:42:41Z

Vinod kumar boppanna: /* Introduction */

POC for QuotaManagement

2014-02-12T12:11:08Z

Vinod kumar boppanna: /* Example 4 */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-02-12T10:39:06Z

Vinod kumar boppanna: /* Example 4 */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-02-11T16:28:11Z

Vinod kumar boppanna: /* POC Demo code */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at 
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-02-11T16:27:56Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== POC Demo code ==
Please check the code snippets for this setup at
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-02-11T16:25:12Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

== Concerns ==
* As nova keeps the complete project hierarchy in the Quotas table, it is necessary to notify nova about any changes in the hierarchy. For example, nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and User removes the project "ProjA1" from the keystone, then nova should be notified about this.

POC for QuotaManagement

2014-02-11T15:35:01Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)" (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"

"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner",
"compute_extension:quotas:update": "rule:admin_or_project_admin",
"compute_extension:quotas:delete": "rule:admin_or_project_admin"

POC for QuotaManagement

2014-02-11T15:30:44Z

Vinod kumar boppanna: /* API URLs */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

The Keystone context will have a field which gives information about the roles at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin": "is_admin:True or roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition 
*Cloud Admin
*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

POC for QuotaManagement

2014-02-11T15:03:26Z

Vinod kumar boppanna: /* Quota Tables */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː
* For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist.
* It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

== Quota Tables ==

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

{| class="wikitable"
|-
! Table || Description || Important Fields
|-
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
|-
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
|-
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
|-
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
|}

The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".

== API URLs ==
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like

PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3

When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user at this level (User A has memeber and project-admin roles at this level). As the user possess the "project-admin" role, the update operation on quotas is allowed.

POC for QuotaManagement

2014-02-11T12:32:45Z

Vinod kumar boppanna: /* Quota Tables */

POC for QuotaManagement

2014-02-11T12:30:28Z

Vinod kumar boppanna: /* Example 1 */

POC for QuotaManagement

2014-02-11T12:26:37Z

Vinod kumar boppanna: /* Implementation */

POC for QuotaManagement

2014-02-11T12:16:36Z

Vinod kumar boppanna: /* Authentication */

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.

== Setup ==

Please see the following picture for an example Hierarchical Multitenancy setup.

[[File:ProjectHierarchy.png|ProjectHierarchy]]

== Authentication ==

Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.

===== Example 1 =====
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH, admin
* ProjH.ProjA, admin
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA2, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
* ProjH.ProjB, admin
* ProjH.ProjB.ProjB1, admin
* ProjH.ProjB.ProjB2, admin
* ProjH.ProjB.ProjB1.ProjB3, admin
* ProjH.ProjB.ProjB1.ProjB4, admin
Noteː For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist

===== Example 2 =====
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA.ProjA1 
Roles (find role at each project level upto the leaf node) 
* ProjH.ProjA.ProjA1, admin
* ProjH.ProjA.ProjA1.ProjA3, admin
* ProjH.ProjA.ProjA1.ProjA4, admin
̽

===== Example 3 =====
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session. 
<ins>Scope</ins> 
ProjH.ProjA 
<ins>Roles (find role at each project level upto the leaf node)</ins> 
* ProjH.ProjA, project-admin
* ProjH.ProjA.ProjA1, project-admin
* ProjH.ProjA.ProjA2, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, project-admin
* ProjH.ProjA.ProjA1.ProjectA3, member
* ProjH.ProjA.ProjA1.ProjectA4, project-admin

===== Example 4 =====
User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

= Implementation =

Please check the following table for the APIs to manage Quotas for Domain, Project and User respectively. These APIs can be used by admin (i.e with role admin) to get the quota limits of any domain/project/user. A non-admin user can only use these APIs to see the quotas of a domain to which he/she belongs or of a project in which he/she is a member. In addition the non-admin user can see his/her own quota limits. To make this possible, Keystone V3 auth tokens needs to be used. The context provided by the token has domain_id, project_id and user_id respectively.

{| class="wikitable"
|-
! Method || URI || Description
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id} || Shows quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
|-
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Shows quotas for a User in a Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id} || Deletes quotas for the domain and for all the projects in this domain (In addition deletes quota for all the users in the projects)
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Deletes quotas for a Project and for all the Users in that Project
|-
| DELETE || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Delete quotas for a User in a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id} || Creates or Updates quotas for the domain
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Creates or Updates quotas for a Project
|-
| PUT || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id}&user_id={user_id} || Creates or Updates quotas for a User in a Project
|}

POC for QuotaManagement

2014-02-11T12:15:43Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T12:15:05Z

Vinod kumar boppanna: /* Example 2 */

POC for QuotaManagement

2014-02-11T11:12:21Z

Vinod kumar boppanna: /* Example 2 */

POC for QuotaManagement

2014-02-11T11:11:46Z

Vinod kumar boppanna: /* Example 2 */

POC for QuotaManagement

2014-02-11T11:11:33Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T11:10:49Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T11:08:09Z

Vinod kumar boppanna: /* Example 1 */

POC for QuotaManagement

2014-02-11T11:07:55Z

Vinod kumar boppanna: /* Example 3 */

POC for QuotaManagement

2014-02-11T11:07:36Z

Vinod kumar boppanna: /* Example 2 */

POC for QuotaManagement

2014-02-11T11:00:52Z

Vinod kumar boppanna: /* Example 2 */

POC for QuotaManagement

2014-02-11T10:59:27Z

Vinod kumar boppanna: /* Example 1 */

POC for QuotaManagement

2014-02-11T10:57:01Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T10:56:25Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T10:54:43Z

Vinod kumar boppanna: /* Explanation */

POC for QuotaManagement

2014-02-11T10:49:52Z

Vinod kumar boppanna: /* Setup */

POC for QuotaManagement

2014-02-11T10:30:40Z

Vinod kumar boppanna: /* Setup */

POC for QuotaManagement

2014-02-11T10:29:08Z

Vinod kumar boppanna: /* Introduction */

File:ProjectHierarchy.png

2014-02-11T10:28:11Z

Vinod kumar boppanna:

POC for QuotaManagement

2014-02-11T10:23:43Z

Vinod kumar boppanna: Created page with "== Introduction == This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup."

== Introduction ==

This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.