This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 2322343 - [RHOSP16.2] Cinder/Nova DB Mismatch After Volume Operations[Volumes stuck in detaching state]
Summary: [RHOSP16.2] Cinder/Nova DB Mismatch After Volume Operations[Volumes stuck in ...
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 16.2 (Train)
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Cinder Bugs List
QA Contact: Yosi Ben Shimon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-10-29 03:29 UTC by Parag Ambre
Modified: 2025-01-22 22:03 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2025-01-22 22:01:21 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker   OSP-33016 0 None None None 2025-01-22 22:01:20 UTC
Red Hat Issue Tracker OSP-33531 0 None None None 2025-01-22 22:03:02 UTC

Description Parag Ambre 2024-10-29 03:29:48 UTC 
Description of problem:

The customer has a large productive cluster and implemented his own backup solution. 
For this he constantly boots containers in his tenant(s), which then automatedly attach a volume and push backup data to it. Then the container self destroys and volume gets detached.

The next container boots and pushes his data to the volume and so on.
So a selected set of volumes are attached/detached dozens of times per day.
The volume acts as a vessel for multiple backup jobs and gets passed around regularly.

The customer is encountering errors during volume attachment, specifically the Invalid volume: volume XXX already attached error. This indicates that the volume, despite being detached in theory, is still perceived as attached by the system, preventing new attachments.

Version-Release number of selected component (if applicable):
RHOSP 16.2


Actual results:
- The operations are not working as expected. 

Expected results:
- This should work seamlessly.
Comment 4 Brian Rosmaita 2024-11-25 20:07:48 UTC 
@pambre Can you make sure that the Cu's script is actually waiting for the detatch to complete (that is, making the detach call and then polling the volume status)? From the script you describe, it could be that the second attach is happening before the volume detatchment has actually occurred.
Note You need to log in before you can comment on or make changes to this bug.