Bug 800829

Summary: Alert count not getting updated in overview section of monitor
Product: [Retired] CloudForms Cloud Engine Reporter: Aziza Karol <akarol>
Component: aeolus-conductorAssignee: Angus Thomas <athomas>
Status: CLOSED EOL QA Contact: Rehana <aeolus-qa-list>
Severity: low Docs Contact:
Priority: medium    
Version: 1.0.0CC: akarol, athomas, cpelland, dajohnso, deltacloud-maint, ssachdev, sseago
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:44:12 UTC Type: ---
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
alert count in zone
none
alerts not updated on monitor none

Description Aziza Karol 2012-03-07 11:07:40 UTC 
Description of problem:


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


How reproducible:


Steps to Reproduce:
I have 3 alerts in the zone called dev. see attached screenshot.alert count 3 is displayed in the dev zone.

but if you see on monitor page, the alert count is still displayed as 0.see  attached screenshot.


  

Expected results:
on monitor page overview section,alert count should get updated




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
Comment 1 Aziza Karol 2012-03-07 11:09:04 UTC 
Created attachment 568249 [details]
alert count in zone
Comment 2 Aziza Karol 2012-03-07 11:11:05 UTC 
Created attachment 568257 [details]
alerts not updated on monitor
Comment 3 Scott Seago 2012-03-07 15:46:57 UTC 
The difference is probably due to different criteria for inclusion in "alerts". We don't have true alerts yet, so that's just counting failed instances. The difference is for the pool/zone alerts, we show _all_ failures in the zone on instances the user is allowed to see (regardless of who launched it). For the monitor page, that's intended as a "personal" view, so the statistics are based on only those instances launched/owned by the current user.

In the case here, were the three failure attempts by the same user as is logged in for the 'monitor' screenshot? If so, this sounds like a documentation issue -- the problem is that the UI itself doesn't explain the exact meaning of the statistics (what's shown, etc). If failures in a pool/zone by the current logged-in user aren't showing up in the 'monitor' view, then it's more likely a software bug here.
Comment 4 Dave Johnson 2012-03-07 19:15:32 UTC 
I believe this has something to do with vanished state not being included in the failed_instance_count but that is merely speculation... I added matt for comment
Comment 5 Scott Seago 2012-03-08 17:16:55 UTC 
I don't know that 'vanished' instances would show up differently in the two views. In the current code it looks like failures include "create_failed", "error", and "vanished"

In any case, there's no expectation/guarantee that all instances showing up in the pool failures list will show up on 'monitor', since the "pool" of instances that we pull from is different. "in this zone" vs. "launched by me", as outlined in comment #3.

Basically if the failures shown in the zone aren't launched by the current logged-in-user they're not supposed to show up on 'monitor', as the statistics are defined right now.
Comment 8 Imre Farkas 2013-01-18 11:03:36 UTC 
I wasn't able to reproduce this one: instance creation failure alerts are showed both at pools#index and pools#show

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