Open Stack

Hi Vinod,

Sorry for the top post, but there is a lot that needs to be done across projects to make the idea of domains and trees actually work. One of the issues which you mention below is the idea of quotas. I was just having a discussion with some folks in IRC about this very issue, and there are quite a few people who would like to help with this. I’m going to send out another email to the list entitled “Hierarchicical Multitenancy Discussion” in a bit on this topic.

Vish

On Jan 20, 2014, at 3:17 AM, 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?
> 
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/d3ef0977/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/d3ef0977/attachment.pgp>