<div dir="ltr">Hi Andrew,<div><br></div><div style>I have addressed a bug here <a href="https://bugs.launchpad.net/nova/+bug/1214523">https://bugs.launchpad.net/nova/+bug/1214523</a> for the sync issue.</div><div style>Codes to try to resolve the problem <a href="https://review.openstack.org/#/c/42966/1">https://review.openstack.org/#/c/42966/1</a></div>
<div style><br></div><div style>Please have a look at the codes, any suggestions would be appreciated !</div><div style><br></div><div style>Thanks</div><div style><br></div><div style>Yingjun</div><div style><br></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/21 Andrew Laski <span dir="ltr"><<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 08/21/13 at 12:02am, Yingjun Li wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for address the issues. About the bad state for fixed_ips,<br>
floating_ips, i think we could make the user_id column=NULL when creating<br>
the quota usage and reservation, so the usages for fixed_ips and<br>
floating_ips will be synced within the project.<br>
Does this make sense?<br>
</blockquote>
<br></div>
On the database side that should address the issue I'm seeing, and will fix the issue with the sync methods for those resources.<br>
<br>
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.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
2013/8/20 Andrew Laski <<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The patch in question (<a href="https://review.openstack.org/**#/c/28232/24" target="_blank">https://review.openstack.org/<u></u>**#/c/28232/24</a><<a href="https://review.openstack.org/#/c/28232/24" target="_blank">https://review.<u></u>openstack.org/#/c/28232/24</a>>)<div class="im">
<br>
adds the ability to track quota usage on a per user basis within a project.<br>
I have run into two issues with it so far: the db migration is incomplete<br>
and leaves the data in a bad state, and the sync methods used during quota<br>
reservations no longer work for fixed_ips, floating_ips, and networks since<br>
they are not tied to a user.<br>
<br></div>
The db migration issue is documented at <a href="https://bugs.launchpad.net/**" target="_blank">https://bugs.launchpad.net/**</a><br>
nova/+bug/1212798 <<a href="https://bugs.launchpad.net/nova/+bug/1212798" target="_blank">https://bugs.launchpad.net/<u></u>nova/+bug/1212798</a>> but the<div class="im"><br>
tl;dr is that the quota usages that were in place before the migration is<br>
run can not be decremented and aren't fixed by the healing sync that<br>
occurs. I sought to address this by introducing a new migration which<br>
performs a full sync of quota usages and removes the bad rows but that led<br>
me to the next issue.<br>
<br>
Some resources can't be synced properly because they're tracked per user<br>
in the quota table but they're not tied to a user so it's not feasible to<br>
grab a count of how many are being used by any particular user. So right<br>
now the quota_usages table can get into a bad state with no good way to<br>
address it.<br>
<br>
Right now I think it will be better to revert this change and re-introduce<br>
it once these issues are worked out. Thoughts?<br>
<br>
As an addendum, the patch merged about a month ago on Jul 25th and looks<br>
to have some minor conflicts for a revert but should be minimally<br>
disruptive.<br>
<br></div>
______________________________<u></u>**_________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.<u></u>**org <<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**<u></u>cgi-bin/mailman/listinfo/**<u></u>openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.<u></u>openstack.org/cgi-bin/mailman/<u></u>listinfo/openstack-dev</a>><br>
<br>
</blockquote></blockquote><div class="HOEnZb"><div class="h5">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div>