Bug 1118083 - Unable to select/act on Resource Type nodes from resource group navigation tree
Summary: Unable to select/act on Resource Type nodes from resource group navigation tree
Keywords:
Status: CLOSED EOL
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Resource Grouping
Version: JON 3.2.1
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: JON 4.0.0
Assignee: RHQ Project Maintainer
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-10 00:43 UTC by Larry O'Leary
Modified: 2019-07-29 14:52 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-07-29 14:52:58 UTC
Type: Enhancement


Attachments (Terms of Use)
Screenshot showing type node can be selected (5.27 KB, image/png)
2014-07-24 16:25 UTC, Larry O'Leary
no flags Details
Screenshot showing type node CANNOT be selected (4.71 KB, image/png)
2014-07-24 16:27 UTC, Larry O'Leary
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1118091 None CLOSED RHQ Agent resources are not being auto-clustered in resource group due to their unique resource keys 2019-07-29 14:52:16 UTC
Red Hat Knowledge Base (Solution) 1125663 None None None Never

Internal Links: 1118091

Description Larry O'Leary 2014-07-10 00:43:34 UTC
Description of problem:
When viewing a compatible group, resources of the same type are grouped together into what appears to be referred to as an AutoCluster. This is similar to AutoGroups when viewing resources in the inventory navigation tree.

However, attempts to select the AutoCluster node fail. This means you can not act on the groups child members as you would an AutoGroup.

This results in loss of functionality of recursive groups. It is not clear if this is a regression.

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

How reproducible:
Always

Steps to Reproduce:
1.  Install JBoss ON system with two or more agents/platforms registered and in inventory.
2.  Create a new dynamic group definition named _All Platforms_:

    *   *Expression*: `resource.type.category = PLATFORM`
    *   *Recursive*: _True_
    
3.  Navigate to the newly created group.
4.  Select _File Systems_.

Actual results:
_File Systems_ cannot be selected.

Expected results:
_File Systems_ should be selected and right hand resource detail panel should show "All Platforms ( File System ) Compatible" along with inventory/alerts and monitoring pages.

Additional info:
To see how this is supposed to look, navigate to a single platform. From the navigation tree you can select "File Systems" without incident.

Comment 1 Jay Shaughnessy 2014-07-10 18:35:14 UTC
I don't think the understanding of autocluster is quite correct in the BZ.

I believe what you are seeing is the expected behavior.  In short, we don't autogroup in the compatible group tree.  Moreover, I don't think we want to go down that path, as it would generated many potentially huge groups in the background. And to be honest, I think it would be confusing.

A recursive compatible group is a way of representing a cluster of resources.  Meaning, it's a great way to view logically equivalent resources.  The tree view of a recursive compatible group is aimed at showing you a "cluster" view.  In fact, calling it "cluster tree" wouldn't be a bad thing.

The tree will include every logically distinct resource under all of the root resources of the group.  For a group of platforms that means it includes all resources for all of the platforms.

Every resource with a different clusterkey will have a node in the tree.  Think of a clusterkey as a resource key that incorporates ancestry, in other words, a logical resource key.  For example, there will be only one CPU0 node:

DynaGroup - All Platforms
    ├── CPUs
        -- CPU0

The CPU0 node represents *all* CPU0 resources across all of the platforms in the group.  That node represents the CPU0 autocluster.  It is backed internally by its own compatible group.

In this BZ the "CPUs" node is being called an autocluster. It's not, it's just an inactive grouping node for a child resource type.  It is being confused with an autogroup node in the resource tree, which looks similar.  In the resource tree we autogroup child resources of the same type.  But if we did something analogous here that group would include all cpus for all platforms.  That quickly gets unwieldly, and actually has nothing to do with a clustered view.

Groups like that should be built by hand, script, or by group definitions.

Having said that, we have thought about offering the ability to generate new groups from tree views.  For example, being able to promote an autogroup to a real group from the resource tree.  Here, we could potentially offer the option to generate a real compatible group of all CPUs from that node.  But we don't want to do anything automatically.

Comment 2 Larry O'Leary 2014-07-10 19:04:13 UTC
(In reply to Jay Shaughnessy from comment #1)
> I don't think the understanding of autocluster is quite correct in the BZ.

I realized this after the BZ was created. Sorry for any confusion for the misrepresentation.

> I believe what you are seeing is the expected behavior.  In short, we don't
> autogroup in the compatible group tree.  Moreover, I don't think we want to
> go down that path, as it would generated many potentially huge groups in the
> background. And to be honest, I think it would be confusing.

Not sure how it would be confusing. The point is that the navigation tree already does this elsewhere in the UI. Being consistent seems less confusing. Granted, perhaps it is not a straight auto-group, the node is still almost identical by name and icon to what can be selected in other places of the resource tree.

If the node isn't going to serve any purpose, why have it? Perhaps the gap in the group navigation tree could be bridged by allowing multi-select on the AutoCluster nodes? Thus allowing one to invoke operations or perform configuration updates on the child cluster members without having to create a bunch of new groups to clutter inventory?

As you are indicating that this is working as designed, I will mark this as an enhancement. It seems that there is still some work to be done here to improve overall usability of the group view. I don't really think "create a new group from this auto-cluster/grouping node" is the solution here. Although that would be a great feature, the user isn't asking to have additional groups and the ability to manage them in the "groups view". The use-case would be to invoke operations, configure monitoring, connections, or even resource configuration based on the parent grouping without the need to create a group for every recursive group node.

Comment 3 Jay Shaughnessy 2014-07-10 21:05:51 UTC
>> If the node isn't going to serve any purpose, why have it?

Like the subcategory nodes in the resource tree, which also are not clickable, these nodes serve an organizational purpose, they maintain the expected type hierarchy.  I'm sure one big flat view would be bad.

My gut feeling is that it's not really a feasible enhancement.

Comment 5 Larry O'Leary 2014-07-24 16:24:10 UTC
(In reply to Jay Shaughnessy from comment #3)
> >> If the node isn't going to serve any purpose, why have it?
> 
> Like the subcategory nodes in the resource tree, which also are not
> clickable, these nodes serve an organizational purpose, they maintain the
> expected type hierarchy.  I'm sure one big flat view would be bad.
> 
> My gut feeling is that it's not really a feasible enhancement.

The subcategory node is different. From a usability perspective, if I compare the resource tree to the group resource tree I get inconsistent behavior. I can click on Network Adapters in one view and act on Network Adapters, but in the other view I can not.

I am not sure why we can't make this logical connection in both trees?

Comment 6 Larry O'Leary 2014-07-24 16:25:54 UTC
Created attachment 920617 [details]
Screenshot showing type node can be selected

In this screen shot we can see that the user is able to select the CPUs resource type node from the navigation tree.

Comment 7 Larry O'Leary 2014-07-24 16:27:52 UTC
Created attachment 920618 [details]
Screenshot showing type node CANNOT be selected

In this screen shot we can see that the user is NOT able to select the CPUs resource type node from the navigation tree. When you compare this screen shot to attachment 920617 [details], it seems that the navigation tree is broken. This is because they look almost identical and therefore a user would expect them to function the same.

Comment 8 Jay Shaughnessy 2014-07-25 13:11:21 UTC
Then my recommendation is to change the look of the group tree such that there is less confusion.  This should involve UX.  They are both trees, yes, but they are not the same thing.  One is the tree representing a recursive compatible group and its hierarchy of clustered resources, and one is the tree representing a single resource and its children.  Each tree offers capabilities unique to what it is.

Comment 10 Filip Brychta 2019-07-29 14:52:58 UTC
JBoss ON is coming to the end of its product life cycle. For more information regarding this transition, see https://access.redhat.com/articles/3827121.
This bug report/request is being closed. If you feel this issue should not be closed or requires further review, please create a new bug report against the latest supported JBoss ON 3.3 version.


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