Hi Andrew, I have addressed a bug here https://bugs.launchpad.net/nova/+bug/1214523 for the sync issue. Codes to try to resolve the problem https://review.openstack.org/#/c/42966/1
Please have a look at the codes, any suggestions would be appreciated ! Thanks Yingjun 2013/8/21 Andrew Laski <andrew.la...@rackspace.com> > 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> >>> <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<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 <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> >>> <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 <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 <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
