Updates:
Status: Fixed
Comment #3 on issue 769 by [email protected]: Failing to obtain
newly 'created' locks
http://code.google.com/p/ganeti/issues/detail?id=769
Actually, that bug has been fixed already---in precisely the way suggested.
commit bb38965c63857d4bfefff5cd4c82a9df51dfdddc
Author: Klaus Aehlig <[email protected]>
Date: Mon May 5 12:08:42 2014 +0200
Handle lock addition as lock acquisitions
From stable-2.12 onwards no longer are explicitly added; they just
exist for all conceivable names/uuids. Nevertheless, addition was
handled special based on the assumption that no one else can have
a lock on an entity that is just being created.
This assumption, however, is wrong for instance names. Consider
the situation that an instance is first destroyed an then an instance
with the same name is created. While is instance is being destroyed,
there is the situation where the instance is still in the configuration
and the destroy job holds a lock on the instance. In that time, another
job, like group_verify_disks, can read the list of instances, decide
to wait for a lock on all the then existing instances, and eventually
get the locks, including the one on the instance just removed. And
while that job still has the (useless) lock, the new creation job can
come to the lock-addition stage.
To live with the presence of those races, just wait for newly added
locks as for any other locks. Any job with a lock on a no longer
existing
entity will release it pretty soon anyway.
Signed-off-by: Klaus Aehlig <[email protected]>
Reviewed-by: Petr Pudlak <[email protected]>
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
