Unnecessary BDM entry is created when attempting to attach the same volume to an instance twice.

[Matthew Roark]

Detailed bug description:
An unnecessary block device mapping (BDM) entry is created in the `block_device_mapping` table of Nova whenever attempting to attach the same volume to an instance twice.

Steps to reproduce:

1. Create a standalone instance.
2. Create a volume in Cinder.
3. Attach the volume to the instance using the 'nova volume-attach' command.

# nova volume-attach <instance-id> <volume-id>

4. Confirm the volume was attached; this can be seen in the 'nova show' output.

# nova show <instance-id>

5. Execute the command from Step #3 to attempt to attach the volume once more. Nova will produce an "Invalid volume" error.

ERROR (BadRequest): Invalid volume: volume <volume-id> status must be 'available'. Currently in 'in-use' (HTTP 400) (Request-ID: req-xxxx)

Expected results:

Nova will throw the error listed above, and not create any additional BDM entries in the Nova database.

Actual result:

Nova throws the error, but proceeds with creating a NULL BDM entry. This can be seen by executing the following MySQL query:

SELECT * FROM block_device_mapping WHERE instance_uuid='XXXX';

Reproducibility:

** See upstream bug: https://bugs.launchpad.net/nova/+bug/1427060

I'm able to reproduce on MOS 8.0.

[root@fuel ~]# fuel fuel-version
api: '1'
auth_required: true
feature_groups:
- mirantis
openstack_version: liberty-8.0
release: '8.0'

[Andrey Volkov (avolkov)]

1. Same bug is on master, it was tried to solve different ways:
- modifying code to check BDM already exists (this can cause race conditions in BDM creation)
- adding unique uuid to BDM model (big change, it isn't finished yet)
2. Bug in downstream, possibly, can be solved in less strict conditions.

Idea:
- Check as early as possible volume is already linked.
- Or rollback changes after error in attachment.

[Andrey Volkov (avolkov)]

Some clarifications.
It's important to notice that new BDM entry is in destroyed state
and it doesn't affect normal operation.
The problem could be if bdm isn't destroyed due external errors (rpc, network).
After such situation, possibly, the wrong bdm can be chosen.
Updated patch https://review.openstack.org/#/c/290793/.

[Roman Podoliaka (rpodolyaka)]

Too late to fix this in 9.1, moving to 9.2.