<div dir="ltr">For what is worth neutron employs "resource trackers" which conceptually do something similar to nova quota usage statistics.<div>Before starting any transaction that can potentially change usage for a given resource, the quota enforcement mechanism checks for a "dirty" marker on the resource tracker.</div><div>If that marker is present, usage data for that resource are calculated from the DB table for the resource. If not, current usage is employed for quota enforcement and the "dirty" flag is set.</div><div><br></div><div>This means that if the process dies in the middle of a transaction, the next transaction will rebuild the correct usage count from the DB.</div><div><br></div><div>Salvatore</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 April 2016 at 14:08, Timofei Durakov <span dir="ltr"><<a href="mailto:tdurakov@mirantis.com" target="_blank">tdurakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I think it would be ok to store persistently quota details on compute side, as was discussed during mitaka mid-cycle[1] for migrations[2]. So if compute service fails we could restore state and update quota after compute restart.</div><div><br></div><div>Timofey</div><div><br></div><div>[1] - <a href="https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking" target="_blank">https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking</a></div><div>[2] - <a href="https://review.openstack.org/#/c/291161/5/nova/compute/background.py" target="_blank">https://review.openstack.org/#/c/291161/5/nova/compute/background.py</a></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Wed, Apr 13, 2016 at 7:27 PM, Dmitry Stepanenko <span dir="ltr"><<a href="mailto:dstepanenko@mirantis.com" target="_blank">dstepanenko@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>Hi Team,<br><br></div><div>I worked on nova quota statistics issue (<a href="https://bugs.launchpad.net/nova/+bug/1284424" target="_blank">https://bugs.launchpad.net/nova/+bug/1284424</a>) happenning when nova-* processes are restarted during removing instances and was able to reproduce it. For repro I used devstack and started nova-api and nova-compute in separate screen windows. For killing them I used ctrl+c. As I found this issue happened if nova-* processes are killed after instance was deleted but right before quota commit procedure finishes.<br><br></div><div>We discussed these results with Markus Zoeller and decided that even though killing nova processes is a bit exotic event, this still should be fixed because quotas counting affects billing and very important for us.<br><br></div><div>So, we need to introduce some mechanism that will prevent us from reaching inconsistent states in terms of quotas. In other words, this mechanism should work in such a way that both instance create/remove operation and quota usage recount operation happened or not happened together.<br></div><div><br></div><div>Any ideas how to do that properly?<br><br></div>Kind regards,<br></div>Dmitry<br></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div>