Open Stack

Hi Vinod,


On Mon, Jan 20, 2014 at 9:47 PM, Vinod Kumar Boppanna <
vinod.kumar.boppanna at cern.ch> wrote:

>  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?
>
>
The V3 API in Havana is experimental and is disabled by default but you can
enabled it by modifying your nova.conf file. There is a section osapi_v3
which has config variable of enabled which if set to True will turn on the
V3 API.
 Note that in Havana there is no python-novaclient support for the V3 API
so you will have to access the REST API directly. However, the
python-novaclient support for the V3 API in the icehouse development is
almost complete.



> 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 nameand details. But it does now show who has created which VM.
>
>
The API does return this information, both in a general instance listing as
well as a detailed listing
or query about a specific instance. On the command line if you do a nova
show <instance_uuid> it will
display the user_id who created the instance.




> 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.
>
>
You can send an extra parameter during the instance creation request
(admin_pass in V2, admin_password in v3) but
it is only supported by Xen I think. Otherwise you can look at using
something like the server_password extension and/or
setting it using cloud-init.



> 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".
>
>
So I think this probably ties in with Keystone domains which we don't
really have much support for in
Nova yet (AFAIK). But we'd still need that bit of extra code for quotas to
understand the
domain/project hierarchy.

Regards,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/0bb7ba38/attachment.html>