Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 878381

Summary: "Instance count" displays wrong values on the Cloud Resource Zone name panel
Product: [Retired] CloudForms Cloud Engine Reporter: Rehana <redakkan>
Component: aeolus-conductorAssignee: Angus Thomas <athomas>
Status: CLOSED EOL QA Contact: Rehana <aeolus-qa-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 1.1.0CC: athomas
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: 2020-03-27 19:48:37 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:
Attachments:
Description Flags
instance_count none

Description Rehana 2012-11-20 10:23:33 UTC
Created attachment 648375 [details]
instance_count

Description of problem:


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


How reproducible:


Steps to Reproduce:
1.login to conductor
2.Launch few instance on any CRZ
3.create some "create_failed" instance ( by stopping dc core service,or by referring to invalid image id)
  
Actual results:
Observed that the Instance count is not displaying the correct count of instance
PFA

Expected results:
Should display correct details

Additional info:
rpm -qa |grep aeolus
aeolus-conductor-0.13.24-1.el6cf.noarch
aeolus-conductor-daemons-0.13.24-1.el6cf.noarch
rubygem-aeolus-cli-0.7.7-1.el6cf.noarch
aeolus-conductor-doc-0.13.24-1.el6cf.noarch
aeolus-configure-2.8.11-1.el6cf.noarch
aeolus-all-0.13.24-1.el6cf.noarch
rubygem-aeolus-image-0.3.0-12.el6.noarch

Comment 2 Imre Farkas 2013-01-18 10:44:02 UTC
I wasn't able to reproduce this one: I created a new instance with stopped deltacloud.core. The instance got into create_failed state and the instance counter was also incremented accordingly.

Could you please check if this bug still exists in master?