[openstack-dev] Havana Release V3 Extensions and new features to quota

Vinod Kumar Boppanna vinod.kumar.boppanna at cern.ch
Mon Jan 20 11:17:18 UTC 2014


Hi,

My name is "Vinod Kumar Boppanna" and I was testing the quota part in the
OpenStack Havana Release. I had installed the Havana Release in a single
VM through RDO process. During testing, i used the AUTH_URL as

OS_AUTH_URL=http://<ip_address>:35357/v2.0/

Because of this, the nova is using the following v2 attributes for the quotas

"compute_extension:quotas:show": "",
"compute_extension:quotas:update": "rule:admin_api",
"compute_extension:quotas:delete": "rule:admin_api",

But there are other quota attributes available for v3 and they are

"compute_extension:v3:os-quota-sets:discoverable": "",
"compute_extension:v3:os-quota-sets:show": "",
"compute_extension:v3:os-quota-sets:update": "rule:admin_api",
"compute_extension:v3:os-quota-sets:delete": "rule:admin_api",
"compute_extension:v3:os-quota-sets:detail": "rule:admin_api",

My question is "how can i use the V3 extensions". I mean, whether i can
use them by changing the AUTH_URL as

OS_AUTH_URL=http://<ip_address>:35357/v3.0/ (but this didn't worked).

I also have a doubt whether RDO process installed the Havana setup with V3
extensions or just V2 extensions?

I could test all the existing quota features with respect to tenant and the users in a tenant.
During this, i had observed the following things

1. Weak Notifications - Let’s say that a user is added as a member of a project and he had created an
    instance in that project. When he logs in to the dashboard he can see that an
    instance has been created by him. Now, the administrator removed his membership
    from the “project”. Now when user logs in, he will not be able to see the
    instance that he created earlier. But the instance still exists and the user can log onto it.
    But if administrator adds him back to the project, then the user is able to see again the same instance.

2. By default the policy.json file allows any user in a project to destroy an instance created by another user
   in the same project

3. I couldn't find a link or page in the dashboard where i can set the
    quota limits of a user in a project. I could do for a project, but not
   for a User. I did set the quota limits for the user using nova commands.

4. When i see instances that have created by users in a project, it
 does not show who has created that instance. For eg: if a project has
 2 users and each user created 1 instance of VM each, then in the
"Instances" link, the dashboard show both the instances with their name
and details. But it does now show who has created which VM.

5. When a VM is created, it normally allows SSH login using the key
   pair generated by the user. But the "console" link provided in the
   "dashboard" only allows login through password. So, i have to atleast
   once login to the VM through command line using the key, sets the root
   password (because during the VM creation, i am not asked to enter the
 root password) and then use the console provided in the dashboard.

We also had a short discussion here (at CERN) to take the quota features further.
Among these features, the first one we would like to have is

Define roles like "Admin" (which is already there), "Domain Admin" and
"Project Admin".  The "Admin" can define different domains in the cloud
and also assign a person as "Domain Admin" to each domain respectively.
Also, the "Admin" will define quota to each "Domain".

The "Domain Admin" role for a person in a Domain allows him/her to define
the "Projects/Tenants" in that domain and also define a person as "Project
Admin" to each project in that domain respectively.  This person will also
define "Quota" for each project with the condition that "the sum of quota
limits of all projects should be less than or equal to its domain quota
limits".

The "Project Admin" can add users to each project and also define "quota"
for each user respectively.

We are thinking of first having this sort of tree hierarchy where the
parent can manage all the things beneath them.

I think for this, we need to have the following things in OpenStack
1. Allow to define roles (this is already there)
2. Define the meaning of these roles in the policy.json file of "nova"
3. Need to add little bit of code to understand this hierarchy and allow
the functionalities explained above.

Once we have this, we can then think of "quota delegation".

Any comments, please let me know...

Regards,
Vinod Kumar Boppanna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140120/50a11bdd/attachment.html>


More information about the OpenStack-dev mailing list