yahoo-eng-team team mailing list archive

[Vladyslav Drok <vdrok@xxxxxxxxxxxx>]

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