Hi,
My name is "Vinod Kumar Boppanna" and I was testing the quota part in the
OpenStack Havana Release. I had installed the Havana Release in a single
VM through RDO process. During testing, i used the AUTH_URL as
OS_AUTH_URL=http://<ip_address>:35357/v2.0/
Because of this, the nova is using the following v2 attributes for the quotas
"compute_extension:quotas:show": "",
"compute_extension:quotas:update": "rule:admin_api",
"compute_extension:quotas:delete": "rule:admin_api",
But there are other quota attributes available for v3 and they are
"compute_extension:v3:os-quota-sets:discoverable": "",
"compute_extension:v3:os-quota-sets:show": "",
"compute_extension:v3:os-quota-sets:update": "rule:admin_api",
"compute_extension:v3:os-quota-sets:delete": "rule:admin_api",
"compute_extension:v3:os-quota-sets:detail": "rule:admin_api",
My question is "how can i use the V3 extensions". I mean, whether i can
use them by changing the AUTH_URL as
OS_AUTH_URL=http://<ip_address>:35357/v3.0/ (but this didn't worked).
I also have a doubt whether RDO process installed the Havana setup with V3
extensions or just V2 extensions?
I could test all the existing quota features with respect to tenant and the
users in a tenant.
During this, i had observed the following things
1. Weak Notifications - Let’s say that a user is added as a member of a project
and he had created an
instance in that project. When he logs in to the dashboard he can see that
an
instance has been created by him. Now, the administrator removed his
membership
from the “project”. Now when user logs in, he will not be able to see the
instance that he created earlier. But the instance still exists and the
user can log onto it.
But if administrator adds him back to the project, then the user is able to
see again the same instance.
2. By default the policy.json file allows any user in a project to destroy an
instance created by another user
in the same project
3. I couldn't find a link or page in the dashboard where i can set the
quota limits of a user in a project. I could do for a project, but not
for a User. I did set the quota limits for the user using nova commands.
4. When i see instances that have created by users in a project, it
does not show who has created that instance. For eg: if a project has
2 users and each user created 1 instance of VM each, then in the
"Instances" link, the dashboard show both the instances with their name
and details. But it does now show who has created which VM.
5. When a VM is created, it normally allows SSH login using the key
pair generated by the user. But the "console" link provided in the
"dashboard" only allows login through password. So, i have to atleast
once login to the VM through command line using the key, sets the root
password (because during the VM creation, i am not asked to enter the
root password) and then use the console provided in the dashboard.
We also had a short discussion here (at CERN) to take the quota features
further.
Among these features, the first one we would like to have is
Define roles like "Admin" (which is already there), "Domain Admin" and
"Project Admin". The "Admin" can define different domains in the cloud
and also assign a person as "Domain Admin" to each domain respectively.
Also, the "Admin" will define quota to each "Domain".
The "Domain Admin" role for a person in a Domain allows him/her to define
the "Projects/Tenants" in that domain and also define a person as "Project
Admin" to each project in that domain respectively. This person will also
define "Quota" for each project with the condition that "the sum of quota
limits of all projects should be less than or equal to its domain quota
limits".
The "Project Admin" can add users to each project and also define "quota"
for each user respectively.
We are thinking of first having this sort of tree hierarchy where the
parent can manage all the things beneath them.
I think for this, we need to have the following things in OpenStack
1. Allow to define roles (this is already there)
2. Define the meaning of these roles in the policy.json file of "nova"
3. Need to add little bit of code to understand this hierarchy and allow
the functionalities explained above.
Once we have this, we can then think of "quota delegation".
Any comments, please let me know...
Regards,
Vinod Kumar Boppanna
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
