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
https://fedorahosted.org/pipermail/aeolus-devel/2011-December/007288.html Posted and pushed.
wait for 0.8.0 or after 0.7.0 to verify
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
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