Bug 2178506 - 17.1 - #3 - VMs in locked state - Fix issues with nova-manage volume_attachment subcommand
Summary: 17.1 - #3 - VMs in locked state - Fix issues with nova-manage volume_attachme...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 17.1 (Wallaby)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z4
: 17.1
Assignee: Amit Uniyal
QA Contact: Ashish Gupta
URL:
Whiteboard:
: 2178500 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-15 06:22 UTC by Amit Uniyal
Modified: 2024-11-21 09:38 UTC (History)
11 users (show)

Fixed In Version: openstack-nova-23.2.3-17.1.20240919170757.2ace99d.el9ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2024-11-21 09:38:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 873648 0 None MERGED Added context manager for instance lock 2024-04-01 05:27:15 UTC
Red Hat Issue Tracker OSP-23093 0 None None None 2023-03-15 06:24:21 UTC
Red Hat Product Errata RHBA-2024:9974 0 None None None 2024-11-21 09:38:25 UTC

Description Amit Uniyal 2023-03-15 06:22:19 UTC
This bug was initially created as a copy of Bug #2178500

I am copying this bug because: 



Work item: fix handling of instance locking. From the email thread:

>> 3- VMs in locked state
>>
>> This may be by design, but I'll say it here and let the compute team
>> decide on the correct behavior.
>>
>> On some failures, like the one from step #1, the refresh script leaves
>> the instance in a locked state instead of clearing it.
> 
> ya that kind of a bug.
> we put it in the locked state to make sure the end user cannot make any action like hard rebooting the instace
> while we are messing with the db. that is also why we require the vm to be off so that they cant power it off
> by sshing in.
> 
> regardless of the success or failure the reshsh command shoudl restore the lock state
> 
> so if it was locked before leave it locked and if it was unlocked leave it unlocked.
> so this sound like a bug in our error handeling and clean up



This bug was initially created as a copy of Bug #2161733

I am copying this bug because: 



Description of problem:

Gorka had to make heavy use of the `nova-manage volume_attachment` commands in resolving an escalation for Ericsson, and he had some feedback for us. We'd like to implement that feedback.

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

From master all the way down to 16.2.

How reproducible:

N/A

Steps to Reproduce:

N/A

Actual results:

N/A

Expected results:

N/A

Additional info:

The thread where Gorka explains his feedback is at [1]. I'll try to break it down into specific fixes/work items in subsequent comments in this BZ.

[1] https://lists.corp.redhat.com/archives/rhos-compute/2022-December/000883.html

Comment 3 Amit Uniyal 2023-08-22 12:11:43 UTC
*** Bug 2178500 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2024-11-21 09:38:22 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (RHOSP 17.1.4 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2024:9974


Note You need to log in before you can comment on or make changes to this bug.