Bug 766038

Summary:	Deleting deployments fails when there is no provider account
Product:	[Retired] CloudForms Cloud Engine	Reporter:	Greg Blomquist <gblomqui>
Component:	aeolus-conductor	Assignee:	Greg Blomquist <gblomqui>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Shveta <ssachdev>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	1.0.0	CC:	akarol, deltacloud-maint, ssachdev, whayutin
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-30 17:17:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Greg Blomquist 2011-12-09 21:34:43 UTC

Description of problem:

I don't know all the ways to get into this situation, but I believe I hit this problem when I try to launch a deployment and it fails during the launch process.  Usually, this is while testing a change to the launch code.

When I hit this scenario, I generally have to manually update the DB to set the instances' states to "stopped" so I can delete them through the web UI.

I added a patch a few days ago to delete config server configs when a deployment is deleted.  And, it's not doing a proper nil check on the instance's provider account.

The end result is that you cannot delete deployments whose instances were never assigned a provider account.

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

Comment 1 Greg Blomquist 2011-12-09 21:48:29 UTC

https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007288.html

Posted and pushed.

Comment 2 wes hayutin 2011-12-10 21:24:09 UTC

wait for 0.8.0 or after 0.7.0 to verify

Comment 3 Shveta 2012-01-18 15:36:07 UTC

the only way I know how to get into this situation is to have a launch that fails
<blomquisg> shveta: that will sometimes leave the instance in a state where it has no provider account set ... depending on how it failed
<blomquisg> shveta: but, it's hard to reproduce, b/c typically those types of failures result from bugs that have already been fixed
<blomquisg> shveta, weshay: an actual "failed" launch will leave the instance in a "failed" state ... but a launch that fails b/c of an uncaught 500 server error can recreate this scenario
<blomquisg> shveta: well, that's just it ... it doesn't actually launch, but attempts to ... if it fails to launch and receives a 500 server error, it can leave the instance in a "new" state

Comment 4 wes hayutin 2012-02-24 05:00:30 UTC

able to delete stopped applications after provider accounts have been removed


[root@qeblade31 yum.repos.d]# rpm -qa | grep aeolus
aeolus-conductor-daemons-0.8.0-35.el6.noarch
rubygem-aeolus-image-0.3.0-9.el6.noarch
rubygem-aeolus-cli-0.3.0-10.el6.noarch
aeolus-all-0.8.0-35.el6.noarch
aeolus-conductor-0.8.0-35.el6.noarch
aeolus-conductor-doc-0.8.0-35.el6.noarch
aeolus-configure-2.5.0-15.el6.noarch