POC for QuotaManagement - Revision history

Vinod kumar boppanna: /* POC Demo code */

2014-04-06T16:32:39Z

‎POC Demo code

Vinod kumar boppanna: /* API URLs */

2014-03-20T12:31:42Z

‎API URLs

Vinod kumar boppanna: /* API URLs */

2014-03-20T12:16:53Z

‎API URLs

Vinod kumar boppanna: /* Concerns */

2014-03-20T12:03:36Z

‎Concerns

Vinod kumar boppanna: /* API URLs */

2014-03-20T12:00:50Z

‎API URLs

Vinod kumar boppanna: /* API URLs */

2014-03-20T12:00:30Z

‎API URLs

Vinod kumar boppanna: /* Authentication */

2014-03-20T11:56:50Z

‎Authentication

Vinod kumar boppanna: /* Authentication */

2014-03-20T11:54:57Z

‎Authentication

Vinod kumar boppanna: /* API URLs */

2014-03-20T11:51:27Z

‎API URLs

Vinod kumar boppanna: /* Authentication */

2014-03-20T11:46:20Z

‎Authentication

@@ Line 100: / Line 100: @@
 == POC Demo code ==
 Please check the code snippets for this setup at  <br/>
-https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/391e9108fa579d292880c8836cadfd7253586f37
+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.

@@ Line 79: / Line 79: @@
 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"
+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"
- "admin_or_project_admin":  "is_admin:True or  roleProjectAdmin:rolesList:%(project_id)s"
+  "context_is_admin":  "role:admin"
 This means that the user satisfies one of the following condition <br/>
 *Cloud Admin
-*function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"
+*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
-  "owner": "roleMember:rolesList:%(project_id)"   (means that user has any role except admin and project-admin in the project)
+  "member": "role:member and project_id:%(project_id)s"   (means that user has role member in the project)
-  "admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"
+  "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",

@@ Line 81: / Line 81: @@
 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)"
+  "admin_or_project_admin":  "is_admin:True or  roleProjectAdmin:rolesList:%(project_id)s"
 This means that the user satisfies one of the following condition <br/>

← Older revision		Revision as of 12:03, 20 March 2014
Line 101:		Line 101:

	== Concerns ==		== 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.	+	* 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.

@@ Line 79: / Line 79: @@
 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"
+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)"

← Older revision		Revision as of 11:56, 20 March 2014
Line 44:		Line 44:

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

@@ Line 11: / Line 11: @@
 == 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.
+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 =====

@@ Line 70: / Line 70: @@
 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.
+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 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"
+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)"
@@ Line 82: / Line 82: @@
 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)
+  "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"