Hi All,
            This is with regard to Nested Quota Implementation in nova.
            The blueprint has been approved for liberty,which was earlier 
approved for kilo.
 
https://review.openstack.org/#/c/160605<https://review.openstack.org/#/c/160605>

         The complete code has been uploaded.

            https://review.openstack.org/#/c/149828/

         There are two issues.
           1. In nested quota, we are making the default quota values as zero. 
This is because, in nested projects, the quota of a child project is limited by 
its parent's free quota. So there is no point in having finite default quota 
values for a project. If I make default quota values as zero,whether it will be 
having any effect on modules in nova other than quota ? Is there any 
dependency,at least in the functional tests ? Actually many tests other than 
quota are failing and I am trying to figure it out.
          2. In nova , we are having context checking in  files such as wsgi.py 
 ,sqlalchemy/db/api.py ,quotas.py ,quota_sets.py etc,out of which wsgi.py and 
api.py are common to many modules other than quota.In nested quota, we are 
making a condition that , to update the quota of a project,the token should be 
scoped to the parent of the project ,rather than to the project itself. This is 
because ,an increase in the quota limit of a child project,results in the 
reduction of free quota of the parent.So, it makes sense to scope the token to 
the parent. But this may or may not be followed by modules other than quota. In 
that case , I think that the context checking should be eliminated from files 
which are common. It will not  create any security problem, since context 
checking is already done by the individual modules themselves.In fact ,I feel 
context checking in common files are redundant.
           Kindly give me your opinion on these issues.Actually there is a 
session for quota in the summit.
                          best regards
                              sajeesh
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to