Bug 1212052 - OpenStack - "unknown attribute: state" when trying to terminate an instance.
Summary: OpenStack - "unknown attribute: state" when trying to terminate an instance.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: GA
: 5.4.0
Assignee: Greg Blomquist
QA Contact: Milan Falešník
URL:
Whiteboard:
Depends On:
Blocks: 1215516
TreeView+ depends on / blocked
 
Reported: 2015-04-15 13:13 UTC by Milan Falešník
Modified: 2015-06-16 12:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1215516 (view as bug list)
Environment:
Last Closed: 2015-06-16 12:58:26 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Excerpt from evm.log (3.68 KB, text/plain)
2015-04-15 13:13 UTC, Milan Falešník
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1100 0 normal SHIPPED_LIVE CFME 5.4.0 bug fixes, and enhancement update 2015-06-16 16:28:42 UTC

Description Milan Falešník 2015-04-15 13:13:59 UTC
Created attachment 1014741 [details]
Excerpt from evm.log

Description of problem:
When trying to terminate an instance, the instance gets terminated, but the task in CFME ends with an error and the instance remains in the database.

Additional info:
TripleO setup


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

How reproducible:
always

Steps to Reproduce:
1. Have an instance in OpenStack
2. Terminate it

Actual results:
Instance gets terminated in the provider but then it shows an error in Configuration/Tasks:

| Status = Error | 04/15/15 13:04:39 UTC | 04/15/15 13:04:33 UTC | Finished | unknown attribute: state | cirros2: 'vm_destroy' | admin |

and the Instance is still shown in the UI (unless you do a manual refresh, then it gets archived)

Expected results:
Instance gets terminated and disappears

Comment 2 Greg Blomquist 2015-04-20 16:15:34 UTC
https://github.com/ManageIQ/manageiq/pull/2680

Comment 3 CFME Bot 2015-04-20 18:31:01 UTC
New commit detected on manageiq/master:
https://github.com/ManageIQ/manageiq/commit/cc051cad27be10586636136bbd6cab8a88c6b6c6

commit cc051cad27be10586636136bbd6cab8a88c6b6c6
Author:     Greg Blomquist <gblomqui>
AuthorDate: Mon Apr 20 11:46:41 2015 -0400
Commit:     Greg Blomquist <gblomqui>
CommitDate: Mon Apr 20 11:46:41 2015 -0400

    Destroying an OpenStack VM should not set state attr
    
    The state attribute on VMs is read only and used purely as a normalization layer
    in order to display a common state for all different types of VMs.
    
    When VMs are destroyed (or, otherwise acted upon), the appliance will set a
    temporary power state in order to reflect the impending change that's been
    submitted to the provider.  The change submitted to the provider is handled
    largely asynchronously with any updates from the change coming in the form of
    events received after the fact.
    
    The temporary power state change when destroying OpenStack VMs was trying to set
    the state attribute.  By changing that to the raw_power_state attribute, the
    power state is updated and reflected in the read only state attribute.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1212052

 vmdb/app/models/vm_openstack/operations.rb |  2 +-
 vmdb/spec/models/vm_openstack_spec.rb      | 17 +++++++++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

Comment 5 Milan Falešník 2015-05-05 13:32:19 UTC
Checked in 5.4.0.0.24.20150427192818_1fd9e49, now there is no error in the task message, the termination happens but there still is the suspended state which persists until next refresh. Is that intended? If yes, then I can move it to VERIFIED.

Comment 6 Milan Falešník 2015-05-07 09:42:14 UTC
5.2.0.0.25 - instance gets archived correctly now. This was probably from the another BZ from power states but I wanted to be sure.

Comment 8 errata-xmlrpc 2015-06-16 12:58:26 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, 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://rhn.redhat.com/errata/RHBA-2015-1100.html


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