Bug 1217219

Summary:	[RuntimeError]: start is not permitted at state finished Method:[rescue in deliver]
Product:	Red Hat CloudForms Management Engine	Reporter:	Thom Carlin <tcarlin>
Component:	SmartState Analysis	Assignee:	Hui Song <hsong>
Status:	CLOSED WORKSFORME	QA Contact:	Vadim Rutkovsky <vrutkovs>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.4.0	CC:	cpelland, dajohnso, jhardy, jprause, obarenbo, roliveri, tcarlin
Target Milestone:	GA	Keywords:	ZStream
Target Release:	5.5.4
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	smartstate:openstack:retest
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-22 12:39:01 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:

Description Thom Carlin 2015-04-29 19:34:41 UTC

Description of problem:

evm.log shows "[RuntimeError]: start is not permitted at state finished  Method:[rescue in deliver]"

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

5.4.0.0.23.20150423131011_69b48fd

How reproducible:

Unsure

Steps to Reproduce:
1. Perform SmartState Analysis on RHOS VM
2.
3.

Actual results:

[RuntimeError]: start is not permitted at state finished  Method:[rescue in deliver]

Expected results:

No error

Additional info:

 MIQ(MiqQueue.deliver)    Message id: [856], Error: [start is not permitted at state finish]

Stack traceback:
/var/www/miq/vmdb/app/models/job/state_machine.rb:31:in `signal'
/var/www/miq/vmdb/app/models/miq_queue.rb:356:in `block in deliver'
/opt/rh/ruby200/root/usr/share/ruby/timeout.rb:66:in `timeout'
/var/www/miq/vmdb/app/models/miq_queue.rb:352: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:323:in `block in do_work_loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:320:in `loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:320:in `do_work_loop'
/var/www/miq/vmdb/lib/workers/worker_base.rb:141:in `run'
/var/www/miq/vmdb/lib/workers/worker_base.rb:122:in `start'
/var/www/miq/vmdb/lib/workers/worker_base.rb:23:in `start_worker'
/var/www/miq/vmdb/lib/workers/bin/worker.rb:3:in `<top (required)>'
/opt/rh/cfme-gemset/bundler/gems/rails-8f014fba21f9/railties/lib/rails/commands/runner.rb:52:in `eval'
/opt/rh/cfme-gemset/bundler/gems/rails-8f014fba21f9/railties/lib/rails/commands/runner.rb:52:in `<top (required)>'
/opt/rh/cfme-gemset/bundler/gems/rails-8f014fba21f9/railties/lib/rails/commands.rb:64:in `require'
/opt/rh/cfme-gemset/bundler/gems/rails-8f014fba21f9/railties/lib/rails/commands.rb:64:in `<top (required)>'
script/rails:6:in `require'
script/rails:6:in `<main>'

VM available demonstrating issue

Comment 2 Mo Morsi 2015-04-30 20:15:04 UTC

Thom, could you share the connection info and credentials of the openstack environment and vm where this issue is present?

Comment 3 Joe Rafaniello 2015-05-01 20:42:58 UTC

Thom, a few additional questions on top of what Mo asked:
1) does this happen to all RHOS vms you fleece(Perform SmartState Analysis)?  do any succeed?

2) can you provide the evm.log containing the fleecing start and error?  We'd need to trace the state machine for the scan job to see why it's finish and then try to transition to start.

Thanks!

Comment 4 Thom Carlin 2015-05-04 14:55:39 UTC

Mo, you already have the connection and credentials supplied from the needinfo? request of the related bz.
Joe: 1) I believe all
2) Evm.log is available using credentials above.

Comment 6 Rich Oliveri 2015-12-14 18:09:19 UTC

Dave, We've found that this type of error is usually indicative of a lower-level failure - the identity of which, obscured by this error. Given we haven't been able to reproduce this, there's a high likelihood that the underlying problem has been addressed and fixed by another BZ/PR. Can you please have this retested?