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 <>

> The patch in question 
> (**#/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**
> 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@lists.openstack.**org <>
OpenStack-dev mailing list

Reply via email to