Bug 800829 - Alert count not getting updated in overview section of monitor
Alert count not getting updated in overview section of monitor
Status: ON_QA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-conductor (Show other bugs)
1.0.0
Unspecified Unspecified
medium Severity low
: rc
: ---
Assigned To: Angus Thomas
Rehana
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-07 06:07 EST by Aziza Karol
Modified: 2016-10-03 07:26 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
alert count in zone (228.29 KB, image/png)
2012-03-07 06:09 EST, Aziza Karol
no flags Details
alerts not updated on monitor (228.25 KB, image/png)
2012-03-07 06:11 EST, Aziza Karol
no flags Details

  None (edit)
Description Aziza Karol 2012-03-07 06:07:40 EST
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 06:09:04 EST
Created attachment 568249 [details]
alert count in zone
Comment 2 Aziza Karol 2012-03-07 06:11:05 EST
Created attachment 568257 [details]
alerts not updated on monitor
Comment 3 Scott Seago 2012-03-07 10:46:57 EST
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 14:15:32 EST
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 12:16:55 EST
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 06:03:36 EST
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?

Note You need to log in before you can comment on or make changes to this bug.