Public bug reported:
Right now the code in compute.api delete methods ignores delete requests
if the instance is already in deleting state
(https://github.com/openstack/nova/blob/69ce0f01b60dfe0f020ac57eb82a42e5935064c4/nova/compute/api.py#L2257-L2262).
It was result of discussion in
https://bugs.launchpad.net/nova/+bug/1248563 and mailing list thread
referenced there. Though right now, after python 2 EOL, it is possible
to allow multiple delete requests, without having to worry about delete
requests piling up waiting on the instance uuid lock, if the lock will
be acquired with timeout. Python 3 supports passing timeout argument to
lock.acquire, so it'll have to be a pretty easy change to
oslo.concurrency to allow passing that timeout through (for example
using acquire call with timeout in
https://github.com/openstack/oslo.concurrency/blob/c08159119e605dea76580032ca85834d1de21d3e/oslo_concurrency/lockutils.py#L156-L162).
The instance deletion flow could then use such way of lock acquisition,
and if it was not acquired, to allow user to retry later.
** Affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1862394
Title:
Nova ignores delete requests while instance is in deleting state
Status in OpenStack Compute (nova):
New
Bug description:
Right now the code in compute.api delete methods ignores delete
requests if the instance is already in deleting state
(https://github.com/openstack/nova/blob/69ce0f01b60dfe0f020ac57eb82a42e5935064c4/nova/compute/api.py#L2257-L2262).
It was result of discussion in
https://bugs.launchpad.net/nova/+bug/1248563 and mailing list thread
referenced there. Though right now, after python 2 EOL, it is possible
to allow multiple delete requests, without having to worry about
delete requests piling up waiting on the instance uuid lock, if the
lock will be acquired with timeout. Python 3 supports passing timeout
argument to lock.acquire, so it'll have to be a pretty easy change to
oslo.concurrency to allow passing that timeout through (for example
using acquire call with timeout in
https://github.com/openstack/oslo.concurrency/blob/c08159119e605dea76580032ca85834d1de21d3e/oslo_concurrency/lockutils.py#L156-L162).
The instance deletion flow could then use such way of lock
acquisition, and if it was not acquired, to allow user to retry later.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1862394/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
