Bug 999110

+1 This creates confusion for JDG customers/prospects. Infinispan is used privately in EAP. In our presentation to customers, we should indicate the functionality of the EAP component, instead of its project name.

The subsystem name would need to be changed, which has significant compatibility implications.

(In reply to Brian Stansberry from comment #2)
> The subsystem name would need to be changed, which has significant
> compatibility implications.

Can you share the implication detail? Are user scripts broken, applications?

Yes, user scripts would be broken. The address of any aspect of the subsystem management model includes the element subsystem=infinispan.

We do have aliasing capabilities in the management model, although we've never tried to use them for an entire subsystem. I expect there would be issue with that.

In a mixed version domain even with aliasing the subsystem is going to be named infinispan on the legacy servers. And any management calls to those servers will have to use the "infinispan" name.

We've changed the UI navigation entries

We did the same thing for these:

JGroups > Group Communication
mod_cluster > Load Balancing
Infinispan > Caching
Jacorb > Corba

(In reply to Heiko Braun from comment #6)
> We did the same thing for these:
> 
> JGroups > Group Communication
> mod_cluster > Load Balancing
> Infinispan > Caching
> Jacorb > Corba

Just to be clear - that is purely a renaming of the items shown in the UI, but not of the underlying subsystems? So subsystem=inifinispan stayed as is?

(In reply to Heiko W. Rupp from comment #7)
> (In reply to Heiko Braun from comment #6)
> > We did the same thing for these:
> > 
> > JGroups > Group Communication
> > mod_cluster > Load Balancing
> > Infinispan > Caching
> > Jacorb > Corba
> 
> Just to be clear - that is purely a renaming of the items shown in the UI,
> but not of the underlying subsystems? So subsystem=inifinispan stayed as is?

Correct. There was no change in the actual addresses of the management resources.

Keyword "infinispan" is still present in a UI:
 - Profile -> Caching -> Cache containers -> "A set of infinispan cache containers."
 - Profile -> Caching -> Cache containers -> Attributes -> Need help? -> "The default infinispan cache"

Keyword "JGroups" is still present in a UI:
 - Profile -> Caching -> Cache containers -> Transport -> Need help? -> "The jgroups stack to use for the transport"

Keyword "mod_cluster" is still present in a UI:
 - Profile -> Web -> Load balancer -> "The modcluster configuration."
 (- Profile -> Web -> Load balancer -> Advertise Socket -> "modcluster") - not sure if renaming is appropriate
 - Profile -> Web -> Load balancer -> Web contexts -> "Enable contexts even if disabled in mod_cluster_manger (httpd)."
 - Profile -> Web -> Load balancer -> Web contexts -> "List of contexts mod_cluster should ignore, Format String separated with commas."

Keyword "Jacorb" is still present in a UI:
 - Profile -> Container -> Corba -> "The JacORB subsystem configuration."

If this creates to much confusion, we can easily roll the UI changes back.

This change would require significant effort on the part of the documentation team because references to menu items are almost certainly mentioned in documentation in both textual and screenshot form.

To determine screenshots affected requires someone to check each image manually for the appearance of items that have changed name. Each then would need to be re-taken.

To determine references in text to menu items that have changed would be more difficult, requiring a combination of a global search *and* manual checking.

Furthermore, since the management model itself is not changing, there would then be inconsistency between instructions given to achieve a task via the management console (MC) versus the command-line interface (CLI). Any references in the MC's help text also need to be changed.

If the changes remain, it can be expected that QE will fail documentation on the basis that the text is inconsistent with the MC itself.

I fully support these changes being made, but their implementation requires more time than we have between now and the EAP 6.2.0 GA.

I have been asked to comment in more detail regarding the inconsistencies these UI changes introduce.

The UI elements in the console are in general visualizations of the underlying resources in EAP's server side management model. For example, the Profile tab's Infinispan menu item was the UI for dealing with the resources under the /subsystem=infinispan branch of the server side management resource tree. Changing the name in the UI to Caching means the same logical resource is now referred to via two different names depending on what tool the user uses for management, with the web console differing from all other tools. This is inconsistent.

I don't know this for a fact, but my expectation is most admins who work with EAP on any significant level will be aware of the true name of the resources, e.g. /subsystem=infinispan. IOW this is not an inconsistency that will fly under the radar due to users being unaware.

Changing the underlying management model names is not possible for 6.2 and IMHO should not be considered for 6.3 without extensive discussion.

Beyond this big issue, there are small inconsistency issues of the type highlighted in Comment #9. Quite a bit of text in the console is coming directly from the server:

- Profile -> Caching -> Cache containers -> "A set of infinispan cache containers."

That text is from the text description of the management resource that is provided by the server. The other examples in that comment except the one below are cases of the same thing.

- Profile -> Web -> Load balancer -> Advertise Socket -> "modcluster"

Here it's the name we give to one of our standard socket binding configs that is at issue. If we change that in our default configs, we may break any users who pick up the new config, don't notice the change, but have CLI scripts etc that assume the old name.

I approve rolling this change back out.

So Heiko (or Harald), I think we all agree this change needs to be reverted, but I assume this is going to happen post-Beta pre-GA? Can someone confirm what is currently used in ER4/Beta?

Also, a general comment:

Those subsystem names shouldn't really change in the model or elsewhere. When we discussed how to call the jacorb subsystem, whether it's CORBA vs Jacorb, it turned out that jacorb is really an important implementation detail that you should not hide/abstract. I.e. if jacorb is replaced by the JDKorb then it's configuration will be most probably very different so you cannot keep one set of compatible settings. The same goes for JBossWeb vs Undertow.

This fix is in 2.0.2, which is included with ER4 ( since yesterday) it looks like we simply forgot to update the release notes: https://bugzilla.redhat.com/show_bug.cgi?id=1014047

I've updated this issue to reflect the inclusion in ER4, like we agreed.

I understood from this discussion that the renaming in the console should NOT be performed (see comment 15). However, it was already done and had to be reverted. In ER4, it is only reverted PARTIALLY and as I confirmed with Heiko, the reverting needs more work. Moving back to assigned.

Fixed Web Console 2.0.3.Final included in EAP 6.2.0 ER 5.

Verified for EAP 6.2.0.ER5

As discussed above the initial change was reverted and currently the project names are displayed

Heiko Braun <ike.braun> updated the status of jira HAL-250 to Resolved

I'm confused by references to Release Notes, mentioned in comment 19. Was this change made in a public release of JBoss EAP, then reverted during the development cycle for JBoss EAP 6.2.0?

It's not in any public release and the cnages have been rolled back.