Add expected_task for instance.save() used by block_device mapping in compute.manager._build_resources

[Zhenyu Zheng]

For large scale deployment, command can be sent concurrently, and for several times, when an instance was asked to be delete during it is launching, we observed that the vm_state and task_state of that instance has changed abnormally like this:

When we delete the instance while its' task state is networking:
scheduling->none->（networking）->deleting->block_device_mapping-->spawing-->none
The expected task_state should be:
networking->deleting->deleted
and the vm_state changes like this:
BUILD-ACIVE-disappear , which is also very strange for user.

After we dive deeper, we found out that in the _build_resource code, the instance.save() for block_device_mapping doesn't contain expected_task_state:
https://git.openstack.org/cgit/openstack/nova/tree/nova/compute/manager.py#n2135 , so it also saved "deleting" and two process keep working which causes the above situation.

How about we add some expected_task_state also for block_device_mapping?
The expected task states can be NETWORKING, SCHEDULING, and none.

[Jay Pipes (jaypipes)]

Is there a patch in progress for this? I don't see one linked...

[Zhenyu Zheng (zhengzhenyu)]

Didn't notice this, the patch for this bug is:

https://review.openstack.org/#/c/245038/

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/288933

[OpenStack Infra (hudson-openstack)]

Change abandoned by Michael Still (<email address hidden>) on branch: master
Review: https://review.openstack.org/245038
Reason: This code hasn't been updated in a long time, and is in merge conflict. I am going to abandon this review, but feel free to restore it if you're still working on this.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Stephen Finucane (<email address hidden>) on branch: master
Review: https://review.opendev.org/288933

[Artom Lifshitz (notartom)]

Hard to reproduce, as it's essentially a race, but feels valid. I'm bumping this down to Low though, as the problem is mostly cosmetic, and doesn't actually prevent an instance from deleting correctly.