Unnecessary BDM entry is created when attempting to attach the same volume to an instance twice.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mirantis OpenStack |
Confirmed
|
Medium
|
Andrey Volkov | ||
8.0.x |
Confirmed
|
Medium
|
Andrey Volkov | ||
9.x |
Confirmed
|
Medium
|
Andrey Volkov |
Bug Description
Detailed bug description:
An unnecessary block device mapping (BDM) entry is created in the `block_
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_
Reproducibility:
** See upstream bug: https:/
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'
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) |
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.