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.la...@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@lists.openstack.**org <OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
