[openstack-dev] [Nova] Proposal to revert per-user-quotas

Vishvananda Ishaya vishvananda at gmail.com
Tue Aug 20 18:41:00 UTC 2013


On Aug 20, 2013, at 9:02 AM, Yingjun Li <liyingjun1988 at gmail.com> 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?

If this is a viable approach, I prefer that we attempt to fix the code in tree. We attempted to get this code in grizzly and had to revert. I'd hate to go through the cycle again in I if we can fix it now.

Vish

> 
> 
> 2013/8/20 Andrew Laski <andrew.laski at rackspace.com>
> The patch in question (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 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
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130820/12e5ebd2/attachment.html>


More information about the OpenStack-dev mailing list