Bug 535327 (RHQ-2034)

Summary: sorting groups by children or descendents
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: No ComponentAssignee: Charles Crouch <ccrouch>
Status: CLOSED NOTABUG QA Contact: Jeff Weiss <jweiss>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2CC: cwelton, dajohnso, hbrock, mazz, whayutin
Target Milestone: ---Keywords: SubBug
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2034
Fixed In Version: 1.4 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-04-01 14:28:35 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 565628, 577853    
Description Flags
sorting-by-descendents.png none

Description Lukas Krejci 2009-04-28 03:52:00 EDT
The sorting of groups by children or descendents seems a bit confusing.

On the attached screenshot for sorting in descending order by descendents you can see that:

First row has 31 unavailable descendents, second row has 3200 available and 22400 unavailable descendents, and the rest of the rows have no descendents.

The behaviour is the same when sorting by children.

What is the logic behind these results?
Comment 1 Corey Welton 2009-08-25 16:02:39 EDT
See if this is an easy fix, otherwise push to 1.4 
Comment 2 Corey Welton 2009-08-26 15:17:50 EDT
Need rationale from dev on this for current behaviour.
Comment 3 Corey Welton 2009-08-26 15:19:47 EDT
Pushed to 1.4
Comment 4 Jeff Weiss 2009-09-17 10:16:25 EDT
Reopening - it's in dev's queue anyway, it doesn't need to be in needinfo state.
Comment 5 Red Hat Bugzilla 2009-11-10 15:56:26 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2034
Imported an attachment (id=368737)
Imported an attachment (id=368738)
Comment 6 Joseph Marques 2010-02-06 16:02:07 EST
(In reply to comment #2)
> Need rationale from dev on this for current behaviour.    

This appears to be working properly.  The sorting action is sorting on the average availability for each group.  So the child column for 'test mixed group', where there are *only* 31 down resources, has an availability of 0%.  For the 'sam group' child column, it's availability is 12.5% (25/(25+175)).  The other groups, since they have no members, have null/unknown availability.  So an ascending sort put them in the following order -- 0%, 12.5%, unknown.  A descending sort would have put them in the opposite order -- unknown, 12.5%, 0%.

Some history...

The original implementation of of this might have seemed a bit more intuitive, because we didn't separate out the UP count from the DOWN count.  Instead, we only showed RED if they were all down, GREEN if they were all up, and YELLOW for everything in between.  Empty groups were still shown as GRAY question mark icons.

When this enhancement was first implemented, I had used 2 explicit columns for each of the children and descendent collections.  This allowed you to sort on the number of up resources or the number of down resources for the children and descendent separately.  For reasons I can't remember anymore, Greg Hinkle didn't like this, and wanted a *single* sort column for the each collection, and thus we have the implementation that this issue was opened against.

If people don't like how it's working today, or if they don't think it's intuitive anymore that's fine.  What would you suggest instead?  I'm flexible.
Comment 7 wes hayutin 2010-02-16 11:59:15 EST
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

new = Tracking + FutureFeature + SubBug
Comment 8 wes hayutin 2010-02-16 12:04:08 EST
making sure we're not missing any bugs in rhq_triage
Comment 9 Joseph Marques 2010-04-27 16:31:00 EDT
Jeff, I'm still willing to get how we display this information.  Do we have suggestions on how this should work?
Comment 13 John Mazzitelli 2011-04-01 14:28:35 EDT
i'm closing this - we sort as best we can. I think it makes at least some sense :)

we can revisit at a later time if we think we need to do something better. At that time, we'll need to define that this "something better" would look like.