Bug 708929 - Creating a compatible group with no members will create a mixed group
Creating a compatible group with no members will create a mixed group
Product: JBoss Operations Network
Classification: JBoss
Component: Resource Grouping (Show other bugs)
JON 3.1.1
Unspecified Unspecified
medium Severity medium
: ---
: JON 3.1.2
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
Blocks: 856599
  Show dependency treegraph
Reported: 2011-05-30 03:41 EDT by Lukas Krejci
Modified: 2013-09-11 06:59 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 856599 (view as bug list)
Last Closed: 2013-09-11 06:59:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lukas Krejci 2011-05-30 03:41:47 EDT
Description of problem:
This is usability issue because a group can be changed from compatible to mixed just by updating the list of its members.

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

How reproducible:

Steps to Reproduce:
1. Click on the "New" button in the list of compatible groups
2. Fill in all the details, select no members of the group, click Finish.
Actual results:
The list of compatible groups doesn't contain the newly created group, no exceptions or info anywhere. On the other hand, the group appears in the list of mixed groups which is confusing.

Expected results:
If I create a compatible group, I'd assume it would stay compatible.

Additional info:
Comment 2 John Mazzitelli 2012-08-30 09:54:43 EDT
OK, first, you do not explicitly create a "mixed" group of "compatible" group now. We used to in the past, but now, you just create a "group". Depending on the members in the group, we automatically change it to mixed or compatible group on the fly.

The "New" button in the UI is the same New button when looking at the compatible group list and mixed groiup list. The UI could be argued to be inferring you are created a compatible group if you are looking at the commpatible group list. But this actually isn't the case.

This BZ should be closed IMO, there is nothing to do here. We've had a history of this "feature" and much discussion over this periodically - some people wanted a 0 member group to be considered a mixed group, some people wanted a 0 member group to be considered a compatible group. The choice was fairly arbitrary and if we don't stop the cycle, we'll just keep waffling back and forth over time :)

A 0 member group is a mixed group. If you have a N-member compatible group and you remove all members, we automatically convert it to a mixed group.

Note that if you have a N-member mixed group, and you remove all members, it stays a mixed group.

IIRC there are other issues with 0-member groups that were considered (I think there are certain query assumptions that had to be made, I can't remember all the details).

Close this BZ and forget it every happened :)
Comment 3 Jirka Kremser 2012-08-30 09:56:11 EDT
I've looked into it and there is a flag on ResourceGroup called groupCategory, however, on many places the fact if the group is compatible or mixed is derived from the resource type.

On ResourceGroupManagerBean, there is method called setResourceType which is called from many other methods for manipulating the group as such, and basically it recalculates whether the group is compatible or mixed.

I've already made some changes to the ResourceGroupManagerBean, but there are so many edge cases in UI. So probably the safest change would be to leave it as it is and inform the user that the resulting group will be mixed when creating empty group and when clicking on "New" from Mixed/Compatible group view and creating the other type of a group, then just inform the user about it and open the appropriate view where the newly created group is present.
Comment 4 Jay Shaughnessy 2012-08-30 09:56:48 EDT
This is more a GUI issue than anything else.  We allow people to do a New from what looks like a compatible group view.  We should change that, perhaps.

A BZ search will reveal that we've been through this before.  The fact is that a compatible group is a group that contains all members of the same type.  An empty group has no members and therefore is semantically unclear.

We specifically decided that an empty group should be Mixed, and the code now supports that.

Put another way, group type can change given changes in membership, this is pretty much ingrained in our design.  To change this by forcing a group type be defined at group creation time, and forced to stay that way, means we would need to rework several things and figure out various other semantics, like autogroup recalculation and such.

So, in short, I disagree with Lukas on this one, and I think the semantics should stay as is. We should do better perhaps in the UI/docs.
Comment 5 Jirka Kremser 2012-08-30 10:09:44 EDT
So what about just letting the user know what is happening and navigate him/her to the view where the new group is present (to mixed or comp. list), because it is really confusing if nothing new appears in UI after successful creation.
Comment 6 Lukas Krejci 2012-08-30 10:10:05 EDT
I agree with Jirka here, that we should at least inform the user what is going to happen if they create a group with no members from the compatible group view. The fact that a mixed group is going to be created and that it won't appear on the list the user is currently at is I think at least worth of a message dialog warning the user about the fact.

I think the main problem is that the UI still tries to persuade the user that there are 2 distinct types of groups, where there really is just "groups" that happen to have different features available based on the type of members they contain (the fact that we internally still flag the groups as mixed or compatible explicitly should be irrelevant to the user, because the groups "flow freely" between the mixed and compatible).

So I'd add a bunch of message dialogs warning the user when the group is transitioning between the states. This should also include the "implicit" state of the new group which is determined by the page the user is creating the group from.
Comment 7 John Mazzitelli 2012-08-30 10:17:18 EDT
Alan s. recommends to ping someone on the UX team re the 0 member group?
There's clearly confusion for users, different opinions and the UX team isn't familiar with groups (so this will bring them up-to-speed)

jkremser and lkrejci point out that it would be nice if the UI redirected to the mixed group view if no resources were added to the group - that could be something they can discuss with UXD about
Comment 8 Jirka Kremser 2012-09-12 07:59:40 EDT
has been fixed in master by b54ce46 and it needs to be cherry-picked once the release branch is ready for accepting the 3.1.2 commits
Comment 9 Charles Crouch 2012-10-30 17:42:09 EDT
> Alan s. recommends to ping someone on the UX team re the 0 member group?
> There's clearly confusion for users, different opinions and the UX team
> isn't familiar with groups (so this will bring them up-to-speed)
Jirka, can you add a comment describing the conversation with UX and what the ultimate conclusion was.
Comment 11 Jirka Kremser 2012-11-02 11:16:34 EDT

branch:  release/jon3.1.x
time:    Wed Sep 12 13:52:08 2012 +0200
commit:  9a1f79fe28c4da127b36864bbd7e3a1a9f38adde
author:  Jirka Kremser - jkremser@redhat.com
message: [BZ 708929 - Creating a compatible group with no members will create a mixed group] If the other type of a group is created the user is navigated to the right list and there is also notification if an empty compatible group (=mixed) is created. (cherry picked from commit b54ce46d2f1bcfbb8e7f5e996521592f008e3f24)

changing status to MODIFIED
Comment 12 Simeon Pinder 2012-11-14 23:54:51 EST
Moving this to ON_QA as available for testing in https://brewweb.devel.redhat.com//buildinfo?buildID=243389.
Comment 13 Filip Brychta 2012-11-15 11:09:10 EST
Verified on 3.1.2.ER1

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