OSGi plugin - Server tab should not depend on "org.apache.karaf:type=instance,*" MBeans

[hawtio]

OSGi plugin - Server tab should not depend on "org.apache.karaf:type=instance,*" MBeans

[grgrzybek]

IMO, hawtio should be Fuse/Karaf agnostic and the info could be obtained from some io.hawt MBean. If hawtio is running not on Karaf or doesn't have access to io.hawt MBeans, it could check other MBeans too - but ideally it should not expect that Karaf MBean has something that's only available in Fuse version of Karaf...

[abkieling]

@jamesnetherton @astefanutti
This issue seems important. I think we should prioritize it and see who can work on it.

[jamesnetherton]

What do we mean by 'old way'? If you're not running in the cloud, presumably instance is the primary means of managing Karaf instances. instance is not officially supported by Fuse Karaf but there's nothing stopping Karaf community users from using it.

We should consider removing the server tab IMO. We don't have equivalent pages for the other runtimes. Most of the info on that page could be looked up from the JMX tree.

[tadayosi]

TBH it's secondhand knowledge for me.

@ffang @grgrzybek Can you please explain why the instance feature is not recommended any more for Karaf?

[grgrzybek]

@tadayosi that's fragile question ;)
when you run fuse-karaf (or plain karaf) you actually have one instance. But when we started doing Fuse 7 standalone, people were complaining that instance:create child started a child which immediately failed because undertow was reusing the same port. Of course you can go explicitly to this child and reconfigure it, but there was no command support for that (like there was with Fuse6/Fabric8 profiles). Patching was working fine, but the lack of professional configuration lead to decision to blacklist this feature.

Of course it turned out that when there's no such feature, we get rid of some important (for hawtio) MBean, so we have to bring it back.

[tadayosi]

OK, so to wrap up, instance is not a recommended way to manage instances on OpenShift/Kubernetes but is still usable standalone. (I think we still recommend Ansible for managing clusters for Fuse standalone though.)

To me, not being recommended on OpenShift/Kubernetes alone is a good reason not to rely on the feature. Currently, the only reason we have to have the instance feature in Karaf OpenShift images is Hawtio requiring it (see https://issues.jboss.org/browse/ENTESB-8098).

@jamesnetherton Actually, Hawtio 1.x on WildFly/JBoss EAP used to have JBoss > Server tab, which was somehow omitted in 2.x. I personally find this tab handy for checking the server runtime versions.

[abkieling]

What are we doing about it, then? What's the actionable task?

[jamesnetherton]

I think we just need to aggregate the info for the server page from different MBeans. Once we've done that we could blacklist the instance feature in fuse-karaf again.

[abkieling]

OK, got it. Let's find out what MBeans can provide the same information and update the issue description.

[jamesnetherton]

We can use the Karaf config MBean to get OSGi configs for org.apache.karaf.shell & org.apache.karaf.management to display:

• SSH host & port
• RMI registry port
• RMI server port

The Karaf system MBean has attributes for:

• Framework
• Name (Maybe we use this to infer 'Is root'? E.g if name == 'root')
• Start Level
• Version

We could use the system MBean getProperty operation to retrieve property 'karaf.home' for:

• Location

PID can be parsed out of the Name attribute of the java.lang.Runtime MBean.

Not sure what to do with 'State'. Maybe we remove this as it's related to the instance stuff that we're removing.

[abkieling]

@tadayosi do you think this issue is still relevant if Hawtio stops supporting future versions of Karaf?

[tadayosi]

Considering Karaf support on OpenShift will be discontinued soon it should be outdated as well. I’m just not sure yet if the community will want Karaf support for Hawtio.next.

[github-actions]

This issue has been automatically marked as stale due to a year of inactivity.
It will be closed if no further activity occurs within 14 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!