Open Stack

On 08/21/13 at 12:02am, Yingjun Li wrote:
>Thanks for address the issues. About the bad state for fixed_ips,
>floating_ips, i think we could make the user_id column=NULL when creating
>the quota usage and reservation, so the usages for fixed_ips and
>floating_ips will be  synced within the project.
>Does this make sense?

On the database side that should address the issue I'm seeing, and will 
fix the issue with the sync methods for those resources.

I would be interested to see how the distinction between user level 
resources and project level resources is handled in the code so that 
these types of accidental bugs are avoided.

>
>
>2013/8/20 Andrew Laski <andrew.laski at rackspace.com>
>
>> The patch in question (https://review.openstack.org/**#/c/28232/24<https://review.openstack.org/#/c/28232/24>)
>> adds the ability to track quota usage on a per user basis within a project.
>>  I have run into two issues with it so far: the db migration is incomplete
>> and leaves the data in a bad state, and the sync methods used during quota
>> reservations no longer work for fixed_ips, floating_ips, and networks since
>> they are not tied to a user.
>>
>> The db migration issue is documented at https://bugs.launchpad.net/**
>> nova/+bug/1212798 <https://bugs.launchpad.net/nova/+bug/1212798> but the
>> tl;dr is that the quota usages that were in place before the migration is
>> run can not be decremented and aren't fixed by the healing sync that
>> occurs.  I sought to address this by introducing a new migration which
>> performs a full sync of quota usages and removes the bad rows but that led
>> me to the next issue.
>>
>> Some resources can't be synced properly because they're tracked per user
>> in the quota table but they're not tied to a user so it's not feasible to
>> grab a count of how many are being used by any particular user.  So right
>> now the quota_usages table can get into a bad state with no good way to
>> address it.
>>
>> Right now I think it will be better to revert this change and re-introduce
>> it once these issues are worked out. Thoughts?
>>
>> As an addendum, the patch merged about a month ago on Jul 25th and looks
>> to have some minor conflicts for a revert but should be minimally
>> disruptive.
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>

>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev