Open Stack

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.laski at 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.laski at 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 at lists.openstack.****org <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>
>>> <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 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>
>>
>
>
> ______________________________**_________________
> 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/9e19e9d3/attachment.html>