Bug 817185
| Summary: | Child compatible group name displayed as ... in navigation tree after a group member's name is changed | ||
|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Larry O'Leary <loleary> |
| Component: | Core UI | Assignee: | Jay Shaughnessy <jshaughn> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.3 | CC: | hrupp, jshaughn |
| Target Milestone: | --- | ||
| Target Release: | RHQ 4.5.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 817165 | Environment: | |
| Last Closed: | 2013-09-01 10:03:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 817165 | ||
|
Description
Larry O'Leary
2012-04-27 23:22:44 UTC
I understand the issue and will look into what can be done. As Larry surmised, the backing group for the AutoCluster is derived by the ClusterKey, which correctly uses resource keys, resource types, and ancestry to determine membership. The assumption is that the members will have the same name, which is a fair assumption as likely the group is comprised of members that are targeted as being managed as an identical group. But I agree that "..." is not appropriate. There are a few options but one option that will not be in play is separate tree nodes based on the resource names. That conflicts with the underlying idea of AutoClusters and recursive compatible groups. The solution will likely be a better node name and, possibly a hover with the varying member names, if possible. Understood. I like the hover idea. This could be useful if the group contains mixed names (web-console.war (7), RENAMED - web-console.war (1))
Of course, just to note, it appears that we already have the concept of "Group Name" for these nodes. The navigation tree just isn't using it. I can even rename the group. By default, the group name is set to the child resource names. However, in the event that they vary, it appears that a generic name is used. As shown in attachment 580878 [details], this is "Group of Embedded Web Application (WAR)" in this case. This name can be set to something else in the same manner a resource can be renamed.
Unfortunately the tree node and the group are not all that easy to coordinate. The node comes before the autocluster backing group. The groups are, for good reason, created (and later updated) lazily, not until the user clicks on the node. It's not feasible to create a hover with the group member names. So, we'll suffice with just changing the "..." to "Group of <ResourceTypeName>". Note that the node name will be localized. When the backing group is created for an autocluster of this type (i.e. with disparate member naming) it assigns the default name of "Group of <ResourceTypeName>". So, we're matching the node name with the group name. Unfortunately, the group name generated on the server is *not* localized (nor could it be, as it is in fact the persisted group name). So, I added some brute force code in the GUI to localize the displayed group name in this situation. (note, I suppose we could have just set the name to something like [<ResourceTypeName>] in all cases and not have had to really do this name mucking, but "Group of" seems nicer.) The reproduction steps above specify that the autocluster group name be edited. This is actually a bug in itself. Like autogroups, generated backing groups are created by RHQ for convenience. They are not user created and should not be editable. I have removed the ability to edit the backing group name and recursivity. It is still quite possible to create the desired situation. Simply create a recursive compatible group of disparate objects. For example, a group of AS5 WAR files. The Web Application Contexts will have disparate members (because they have the same clusterKey but different resource names). Note that this whole scenario will probably be rare as recursive compat groups are typically used for a group of like, not disparate, resources. Such as a group of logically equivalent App Servers (i.e. a "cluster"). master commit 87d76b8a0b4f8138d192b2f2b809a18b98e8239a - Now displays localized version of "Group of [<ResourceTypeName>] for: - AutoCluster Tree Node - AutoCluster Group Detail Title bar - AutoCluster Group Detail General properties - No longer allow editing of AutoCluster Group Detail General properties Test Notes: please read comment #3 for more info. Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since. |