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):
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_.
_File Systems_ cannot be selected.
_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.
To see how this is supposed to look, navigate to a single platform. From the navigation tree you can select "File Systems" without incident.
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
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.
(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.
>> 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.
(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?
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.
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.
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.
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.