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

Bug #1602483 reported by Matthew Roark
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mirantis OpenStack
Andrey Volkov
Andrey Volkov
Andrey Volkov

Bug Description

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';


** 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
- mirantis
openstack_version: liberty-8.0
release: '8.0'

Tags: area-nova
Changed in mos:
assignee: nobody → MOS Nova (mos-nova)
importance: Undecided → Medium
milestone: none → 9.1
status: New → Confirmed
tags: added: area-nova
Changed in mos:
assignee: MOS Nova (mos-nova) → Andrey Volkov (avolkov)
Revision history for this message
Andrey Volkov (avolkov) wrote :

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.

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

Revision history for this message
Andrey Volkov (avolkov) wrote :

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/.

Revision history for this message
Roman Podoliaka (rpodolyaka) wrote :

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

Changed in mos:
milestone: 9.1 → 9.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.