Jump to: navigation, search

Difference between revisions of "POC for QuotaManagement"

(→‎Authentication)
(→‎Implementation)
Line 56: Line 56:
 
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".
 
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 =
+
== Quota Tables ==
  
−
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.  
+
There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.  
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
−
! Method || URI || Description
+
! Table || Description || Important Fields
 
|-
 
|-
−
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id} || Shows quotas for a Domain
+
| quotas || Stores the quota values for resources (like instances, cores etc) of a Project || project_id
 
|-
 
|-
−
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}/defaults || Shows default quotas for a Domain
+
| project_user_quotas || Stores the quota allotment to a User in a Project || project_id, user_id
 
|-
 
|-
−
| GET || v2/{tenant_id}/domain-quota-sets/{domain_id}?project_id={project_id} || Shows quotas for a Project
+
| quota_usages || Stores the quota already in use by a User in a Project || project_id, user_id
 
|-
 
|-
−
| 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
+
| reservations || Stores the reservations made for a resource by a User in a Project || project_id, user_id
−
|-
 
−
| 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
 
 
|}
 
|}

Revision as of 12:26, 11 February 2014

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.

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.
Scope
ProjH
Roles (find role at each project level upto the leaf node)

  • 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.
Scope
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.
Scope
ProjH.ProjA
Roles (find role at each project level upto the leaf node)

  • 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.

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
Retrieved from "https://wiki.openstack.org/w/index.php?title=POC_for_QuotaManagement&oldid=41875"