RFE: Create Multiple Servers fails when a volume is specified even with a multiattach volume

It looks to me that the multiattach feature wasn't fully taking care of all the corner cases, including the multiple create call.

Leaving that bug open for now in order to tackle that specific issue, but honestly I feel from a tracking perspective that a specless BP would be more appropriate.

The next problem is hit in the n-api create code. During multi-instance create, for each instance, the method _validate_bdm is called on the common volume. When this is called for the first instance, it calls _check_attach_and_reserve_volume, which calls cinder to do an attachment_create to reserve the volume. So far so good.

Then when going thru the next instance, that call will now fail because the volume now in state 'reserved', and trying to reserve an already reserved volume gives you this:

Feb 08 10:17:16 ub16-ui-dev3 <email address hidden>[21240]: ERROR nova.volume.cinder [None req-1ee86e69-221a-485f-ae0c-4e5b68b564f7
tempest-MultipleCreateTestMultiAttachJSON-1625242046 tempest-MultipleCreateTestMultiAttachJSON-1625242046] [instance: 4a050b18-ea1e-437b-91c7-1d50f294a9d4]
Create attachment failed for volume 0d36be4c-d3eb-4593-8bd6-1755c88efdb7. Error: Invalid volume: Volume 0d36be4c-d3eb-4593-8bd6-1755c88efdb7
status must be available or in-use or downloading (HTTP 400) (Request-ID: req-016ed7db-71b5-454f-bc7b-7e0930f231f2) Code: 400: BadRequest:
Invalid volume: Volume 0d36be4c-d3eb-4593-8bd6-1755c88efdb7 status must be available or in-use or downloading (HTTP 400)

Normally, when you do individual instance creates, this doesn't happen because the volumes are actually attached before the next instance is created and the status is in-use which is legit for multi-attach.

It feels like any fix for this may involve both cinder and nova.

Created related blueprint: https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements