Bug 1215516

Summary: OpenStack - "unknown attribute: state" when trying to terminate an instance.
Product: Red Hat CloudForms Management Engine Reporter: Nikhil Gupta <ngupta>
Component: ProvidersAssignee: Greg Blomquist <gblomqui>
Status: CLOSED ERRATA QA Contact: Shveta <sshveta>
Severity: high Docs Contact:
Priority: high    
Version: 5.3.0CC: dajohnso, dclarizi, drieden, gblomqui, jfrey, jhardy, mfalesni, mfeifer, obarenbo, sshveta
Target Milestone: GAKeywords: ZStream
Target Release: 5.3.5   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 5.3.5.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1212052 Environment:
Last Closed: 2015-07-15 12:55:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1212052    
Bug Blocks:    

Comment 1 Nikhil Gupta 2015-04-27 04:58:43 UTC
When trying to terminate an OpenStack instance, the evm.log shows:
[----] E, [2015-04-24T09:54:24.415276 #2488:ebe010] ERROR -- : MIQ(MiqQueue.deliver)    Message id: [49000002455209], Error: [unknown attribute: state]
[----] E, [2015-04-24T09:54:24.415457 #2488:ebe010] ERROR -- : [ActiveRecord::UnknownAttributeError]: unknown attribute: state  Method:[rescue in deliver]
[----] E, [2015-04-24T09:54:24.415530 #2488:ebe010] ERROR -- : /opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/attribute_assignment.rb:88:
in `block in assign_attributes'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/attribute_assignment.rb:78:in `each'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/attribute_assignment.rb:78:in `assign_attributes'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/persistence.rb:227:in `block in update_attributes!'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/transactions.rb:313:in `block in with_transaction_returning_status'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/connection_adapters/abstract/database_statements.rb:197:in `transaction'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/transactions.rb:208:in `transaction'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/transactions.rb:311:in `with_transaction_returning_status'
/opt/rh/ruby193/root/usr/share/gems/gems/activerecord-3.2.17/lib/active_record/persistence.rb:226:in `update_attributes!'
/var/www/miq/vmdb/app/models/vm_openstack/operations.rb:8:in `raw_destroy'
/var/www/miq/vmdb/app/models/vm_or_template/operations.rb:57:in `vm_destroy'
/var/www/miq/vmdb/app/models/miq_queue.rb:361:in `block in deliver'
/opt/rh/ruby193/root/usr/share/ruby/timeout.rb:69:in `timeout'
/var/www/miq/vmdb/app/models/miq_queue.rb:357:in `deliver'
/var/www/miq/vmdb/lib/workers/queue_worker_base.rb:107:in `deliver_queue_message'
/var/www/miq/vmdb/lib/workers/queue_worker_base.rb:135:in `deliver_message'
/var/www/miq/vmdb/lib/workers/queue_worker_base.rb:152:in `block in do_work'
/var/www/miq/vmdb/lib/workers/queue_worker_base.rb:146:in `loop'
/var/www/miq/vmdb/lib/workers/queue_worker_base.rb:146:in `do_work'
/var/www/miq/vmdb/lib/workers/worker_base.rb:317:in `block in do_work_loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:314:in `loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:314:in `do_work_loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:135:in `run'
/var/www/miq/vmdb/lib/workers/worker_base.rb:123:in `start'
/var/www/miq/vmdb/lib/workers/worker_base.rb:23:in `start_worker'
/var/www/miq/vmdb/lib/workers/bin/worker.rb:5:in `<top (required)>'
/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.17/lib/rails/commands/runner.rb:52:in `eval'
/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.17/lib/rails/commands/runner.rb:52:in `<top (required)>'
/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.17/lib/rails/commands.rb:64:in `require'
/opt/rh/ruby193/root/usr/share/gems/gems/railties-3.2.17/lib/rails/commands.rb:64:in `<top (required)>'
script/rails:6:in `require'
script/rails:6:in `<main>'


Our CFME version is:
[root@oclcloup10 log]# rpm -qa | grep -i cfme
cfme-5.3.3.2-1.el6cf.x86_64
mingw32-cfme-host-5.3.3.2-1.el6cf.x86_64
cfme-lib-5.3.3.2-1.el6cf.x86_64
cfme-appliance-5.3.3.2-1.el6cf.x86_64

The instance is deleted correctly, but I think we are hitting this bug -> https://bugzilla.redhat.com/show_bug.cgi?id=1212052

Therefore I have clone it for cfme-5.3.3.2-1.el6cf.x86_64

Comment 6 CFME Bot 2015-05-07 20:35:58 UTC
New commit detected on cfme/5.3.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=150813561fea1dee7a04f9b5f2f9fb17f596d3f1

commit 150813561fea1dee7a04f9b5f2f9fb17f596d3f1
Author:     Greg Blomquist <gblomqui>
AuthorDate: Mon Apr 20 11:46:41 2015 -0400
Commit:     Greg Blomquist <gblomqui>
CommitDate: Thu May 7 15:31:03 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=1215516
    
    Conflicts:
    	vmdb/app/models/vm_openstack/operations.rb

 vmdb/app/models/vm_openstack/operations.rb |  6 +++---
 vmdb/spec/models/vm_openstack_spec.rb      | 17 +++++++++++++++++
 2 files changed, 20 insertions(+), 3 deletions(-)

Comment 7 CFME Bot 2015-05-07 20:36:02 UTC
New commit detected on cfme/5.3.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=9ed62f9bef2cc910eb4d0aaf302c326e4dcd8967

commit 9ed62f9bef2cc910eb4d0aaf302c326e4dcd8967
Merge: 00cfc41 1508135
Author:     Jason Frey <jfrey>
AuthorDate: Thu May 7 16:31:16 2015 -0400
Commit:     Jason Frey <jfrey>
CommitDate: Thu May 7 16:31:16 2015 -0400

    Merge branch 'bz1215516-cherrypick-1212052' into '5.3.z'
    
    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=1215516
    
    Conflicts:
    	vmdb/app/models/vm_openstack/operations.rb
    
    See merge request !44

 vmdb/app/models/vm_openstack/operations.rb |  6 +++---
 vmdb/spec/models/vm_openstack_spec.rb      | 17 +++++++++++++++++
 2 files changed, 20 insertions(+), 3 deletions(-)

Comment 9 Shveta 2015-07-01 04:14:52 UTC
Configuration/tasks does not show error .
instance terminates and disappears
Verified in 5.3.5.1.20150630091250_5515226

Comment 11 errata-xmlrpc 2015-07-15 12:55:24 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-1223.html