On 4/14/2016 3:07 PM, Andrew Laski wrote:
On Wed, Apr 13, 2016, at 12:27 PM, Dmitry Stepanenko wrote:
Hi Team,
I worked on nova quota statistics issue
(https://bugs.launchpad.net/nova/+bug/1284424) happenning when nova-*
processes are restarted during removing instances and was able to
reprodu
On Wed, Apr 13, 2016, at 12:27 PM, Dmitry Stepanenko wrote:
> Hi Team,
> I worked on nova quota statistics issue
> (https://bugs.launchpad.net/nova/+bug/1284424) happenning when nova-*
> processes are restarted during removing instances and was able to
> reproduce it. For repro I used devstac
For what is worth neutron employs "resource trackers" which conceptually do
something similar to nova quota usage statistics.
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.
Hi,
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.
Timofey
[1] - https://etherpad.openstack.org/p/mitaka-nova-pri
Hi Team,
I worked on nova quota statistics issue (
https://bugs.launchpad.net/nova/+bug/1284424) 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 ki