Bug 800829 - Alert count not getting updated in overview section of monitor
Summary: Alert count not getting updated in overview section of monitor
Keywords:
Status: CLOSED EOL
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-conductor
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
Assignee: Angus Thomas
QA Contact: Rehana
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-07 11:07 UTC by Aziza Karol
Modified: 2020-03-27 19:44 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-03-27 19:44:12 UTC
Embargoed:


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

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?


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