Open Stack

On Fri, 2015-04-10 at 02:38 -0400, Attila Fazekas wrote:
> I noticed the nova DB has reservations table with an expire field (+24h) and a periodic task
> in the scheduler (60 sec) for expire the otherwise not deleted records [2].
> 
> Both the table and the observed operations are strange.
> 
> What this table and its operations are trying to solve ?
> Why does it needed ? 
> Why this solution was chosen ?

It might help to know that this is reservations for the quota system.
The basic reason that this exists is because of parallelism: say the
user makes a request to boot a new instance, and that new instance would
fill their quota.  Nova begins processing the request, but while it's
doing so, the user makes a second (or third, fourth, fifth, etc.)
request.  With a reservation, we can count the first request against
their quota and reject the extra requests; without a reservation, we
have no way of knowing that nova is already processing a request, and so
could allow the user to vastly exceed their quota.

> PS.: 
> Is the uuid in the table referenced by anything?

Once the operation that allocated the reservation completes, it either
rolls back the reservation (in the case of failure) or it commits the
reservation (updating a cache quota usages table).  This involves
updating the reservation table to delete the reservation, and a UUID
helps match up the specific row.  (Or rows; most operations involve more
than one quota and thus more than one row.)  The expiration logic is to
deal with the case that the operation never completed because nova
crashed in the middle, and provides a stop-gap measure to ensure that
the usage isn't counted against the user forever.
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>
Rackspace