Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: My vsphere instances failed to launch due to request time out.(logged https://bugzilla.redhat.com/show_bug.cgi?id=800818). 2.later when i checked the failed vsphere instance state,its displayed as vanished.see attach screenshot. export.csv of on of the failed vsphere instance: Source_type;Source_id;Description;Summary;Status_code;Event_time Instance;13;;created;;2012-03-07 07:30:48 UTC Instance;13;;state changed to create_failed;create_failed;2012-03-07 07:31:34 UTC Instance;13;;state changed to vanished;vanished;2012-03-07 07:32:26 UTC Instance;13;;Instance disappeared from cloud provider;vanished;2012-03-07 07:32:27 UTC but if you check the application state,it is showing as stopped. see attach screenshot of application state. The alert state is vanished and if you see the failed alert count in zone is 3. so there is an inconsistency is states. Actual results: inconsistency in states. Expected results: proper states should be displayed. Additional info: rpm -qa | grep aeolus aeolus-configure-2.5.0-17.el6.noarch aeolus-conductor-0.8.0-40.el6.noarch aeolus-conductor-doc-0.8.0-40.el6.noarch aeolus-all-0.8.0-40.el6.noarch rubygem-aeolus-cli-0.3.0-12.el6.noarch aeolus-conductor-daemons-0.8.0-40.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-configserver-0.4.6-0.el6.noarch
Created attachment 568271 [details] instance in vanished state
Created attachment 568272 [details] application in stopped state
Also i see that due to all this inconsistency in states the failed count in overview section of monitor page is not getting updated. it still shows o instead of 3. see attached screenshot
Created attachment 568276 [details] fail count
So this seems like this is fall out from the addition of the vanished state (related to Bug 795891). I recreated the issue when I pushed a image to vsphere, deleted the image from the vsphere ui, and deploy a blueprint pointed at this image which no longer existed in vsphere. The deployment failed with create_failed but upon a refresh, the state transitioned to vanished which doesn't seem correct. Also, wondering about aziza's comment 2 & 3... I believe she opened a separate issue with bug 800837 Re-assigning to matt Marking as a soft medium as it can cause confusion
Actually, I am thinking aziza's comment 2 & 3 point to bug 800829
I think what we should do here is, if an instance ends up in create_failed, leave it in that state. This is already how we handle stopped instances.
On list: http://lists.fedorahosted.org/pipermail/aeolus-devel/2012-March/009456.html
Pushed to master: commit 239e651c106747f60330ac5d198986e6f49784c1 Author: Matt Wagner <matt.wagner> Date: Wed Mar 7 17:31:47 2012 -0500 BZ 800849 - CREATE_FAILED instances will not be marked as vanished Since they were never created on the backend provider, it doesn't make a lot of sense to mark them as "vanished." It's also a bad user experience. Instead, if an instance fails to get created, leave it in that state. This resolves https://bugzilla.redhat.com/show_bug.cgi?id=800849 and likely https://bugzilla.redhat.com/show_bug.cgi?id=800837 too.
Mike did this get in?
The code landed in master after the freeze/cut-over and didn't have blocker+ so it is not currently in the product rpm. This looks severe enough that we should blocker+ it and pull it into the rpm.
As per comment 5, i tried creating create_failed instance, observed that the instance status was set to "Create_failed" Also observed that for application the status was still showing as "stopped" raised a separate bug to track this issue ;https://bugzilla.redhat.com/show_bug.cgi?id=816194 verified on; rpm -qa | grep aeolus aeolus-conductor-0.8.13-1.el6_2.noarch aeolus-configure-2.5.3-1.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-all-0.8.13-1.el6_2.noarch aeolus-conductor-doc-0.8.13-1.el6_2.noarch aeolus-conductor-daemons-0.8.13-1.el6_2.noarch
Reopening this bug as this is a regression. Vanished state is displayed for failed vsphere instance. see attached screenshot. #rpm -qa | grep aeolus aeolus-configure-2.5.3-1.el6.noarch aeolus-conductor-0.8.13-1.el6_2.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-all-0.8.13-1.el6_2.noarch aeolus-conductor-doc-0.8.13-1.el6_2.noarch aeolus-conductor-daemons-0.8.13-1.el6_2.noarch
Created attachment 581548 [details] vanished state
bumping to 1.0.z, 1.1.0
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. http://rhn.redhat.com/errata/RHEA-2012-0583.html
Reopening, it appears this issue may remain, and was not resolved in cloudforms 1.0. akarol: Can you indicate whether this problem remains OPEN in CloudForms-1.0.1?
I just spent a while attempting to reproduce this, but I cannot get a failed instance to move to vanished. The create_failed -> vanished instance transition should not longer be possible. I will attach a screenshot showing a deployment history for me, after a forced vSphere deployment failure. I'm going to move this back over to ON_QA. If you do run into this problem again, would you mind contacting me so we can try to figure out what's different?
Created attachment 607949 [details] create_failed persists
I can't reproduce this either by deleting the template from the target provider and trying to relaunch the app.
Create failed state is displayed for failed vsphere instances. see attached screenshot verified: rpm -qa | grep aeolus aeolus-conductor-0.13.21-1.el6cf.noarch aeolus-conductor-daemons-0.13.21-1.el6cf.noarch aeolus-configure-2.8.9-1.el6cf.noarch aeolus-all-0.13.21-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-conductor-doc-0.13.21-1.el6cf.noarch rubygem-aeolus-cli-0.7.6-1.el6cf.noarch
Created attachment 633323 [details] vsphere