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

Yingjun Li liyingjun1988 at gmail.com
Tue Aug 20 16:02:53 UTC 2013


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?


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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130821/4e57f933/attachment.html>


More information about the OpenStack-dev mailing list