Hawtio
Hawtio Roadmap 2024 #3400
Replies: 2 comments 1 reply
-
|
Hello
Great and amazing summary!
I assigned myself to:
* FlightRecording one: hawtio/hawtio-next#643
* Implement RBAC support for Quarkus and Spring Boot:
#3045
* New protocols: hawtio/hawtio-next#170
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you! While I wrote as "new protocols alternative to JMX/Jolokia", as you suggest supporting new protocols within Jolokia is also a great idea to explore. That would also keep Jolokia relevant and active in the future. |
Beta Was this translation helpful? Give feedback.
-
|
I assigned myself to Patternfly migration, all-tough we should discuss further we we won't migrate directly to 6 if the release is so close. I can also work on Kaoto+Hawtio integration on the component level, especially sharing the visualisation part. |
Beta Was this translation helpful? Give feedback.
-
About two weeks ago we released Hawtio 4.0.0 GA. 4.0.0 is mainly a release aimed at supporting new technology stacks, which has made Hawtio fully available with the modern Java ecosystem (Jakarta EE 9+, Quarkus 3, Spring Boot 3, and Apache Camel 4).
Now the project can look to the future and start working on new features. We are already a quarter of the way through 2024, and I'd like to share the themes and new features that the team is planning to work on this year.
Common:
Hawtio Online:
Continuous improvement of Hawtio based on community feedback
We already have users who've been trying out the new Hawtio since the 3.0 GA and 4.0 beta versions. We have also already received reports of bugs and feature improvements from the users. We will continue to address these existing reports that were not incorporated into the 4.0.0 GA, as well as the following reports we will continue to accept:
PatternFly upgrade to v5 / v6
When we started developing Hawtio v3, the latest version of PatternFly was still v4. Therefore, we decided to use PatternFly v4 as the UI base until the GA release of Hawtio v3 and v4. However, the latest PatternFly is already v5 and v6 release is planned for later this year.
Therefore, as a major initiative immediately after the release of Hawtio 4.0.0, we plan to migrate to PatternFly v5 and have already started work on this.
We will also start looking at migrating to v6 later in the year.
Restore Dashboard feature
The good old Hawtio v1 had an eye-catching feature: Dashboard. However, in the process of moving to PatternFly with Hawtio v2, the feature was temporarily discontinued as there was no corresponding feature in PatternFly v3 at the time.
Now that Hawtio v4 has matured as a management console, and as we look to further increase integration into Kubernetes/OpenShift through Hawtio Online, we are looking to bring back the dashboard functionality again.
To implement the dashboard, the part of the React UI components implemented in hawtio-next needs to be improved as follows:
Integration with Kaoto at component level
Kaoto is a sister project to Hawtio as a visual tooling for Apache Camel. Whereas Hawtio provides runtime visual views for Camel routes, Kaoto is a design-time visual editor for them. Despite the differences, they share many common features in terms of graphically displaying and editing Camel routes.
Therefore, in order to accelerate the evolution of the two projects together, we will explore the possibility of sharing functionality at component level. Sharing the Camel editor at component level would offer many benefits to the users, such as common functionality and look and feel between the two tools.
Implement RBAC support for Quarkus and Spring Boot
RBAC was one of the outstanding features of Hawtio v2, but was only offered for limited runtimes (Apache Karaf, Apache ActiveMQ Artemis, and Hawtio Online) due to mandatory backend support. Even in Hawtio v4, RBAC is currently only supported by Hawtio Online and Apache ActiveMQ Artemis.
Extending this RBAC support to the primary runtimes, Quarkus and Spring Boot, will be one of the major goals this year.
Flight Recorder plugin (a.k.a. Diagnostics plugin)
The Diagnostics plugin was an excellent plugin that @skarsaune contributed to Hawtio v2. Unfortunately we haven't had time to port it to Hawtio v4 so far. But, as it would be too good to discontinue it as it is, we are planning to port it to v4.
Exploring new protocols alternative to JMX/Jolokia
Hawtio v4 fully supports Quarkus along with Spring Boot as runtime. However, it does not provide a Quarkus plugin equivalent to Spring Boot plugin at the Hawtio UI level. We haven't been able to provide a Quarkus plugin, because Quarkus is a framework that assumes native Java builds and thus, unlike Spring Boot, does not provide standard MBeans to manage applications via JMX which has less affinity with native builds.
In order to provide a UI plugin equivalent to Spring Boot for Quarkus, support for a protocol different from JMX/Jolokia should be considered. As applications become more cloud-native, more and more frameworks are providing health check endpoints etc. that do not rely on JMX. It is therefore worth considering support for protocols other than JMX for the future of Hawtio.
Hawtio Online: Performance improvement
While the original issue is not specific to Hawtio Online, reports have been raised of performance issues when viewing fairly large Camel applications or Artemis brokers with many destinations on the Hawtio console. It is one of Hawtio's goals to be able to run nimbly at the scale of such practical level applications. In particular, Hawtio Online is prone to these scaling-related performance impacts due to differences in deployment architecture.
Therefore, while we work on performance tuning of Hawtio as a whole, this year we will primarily focus on optimising Hawtio Online.
Furthermore, Hawtio currently supports multiple LTS versions of the Camel model. This requires the inclusion of two or more Camel model definitions in the Hawtio UI bundle, and its large definition files are downloaded on page load, resulting in very slow initial loading of the Hawtio console. This is a particularly noticeable problem with Hawtio Online deployed on a remote cluster.
Making the Camel models lazy loaded should solve the performance problem during initial page loading of Hawtio Online.
Hawtio Online: Integrate more into OpenShift
Hawtio Online already integrates Hawtio with OpenShift/Kubernetes by providing the Operator, but we are aiming for further integration and more cluster-native user experiences.
One of the initiatives is to allow Hawtio Online to be installed as a dynamic plugin for OpenShift. If realised, this would provide three ways to deploy Hawtio Online to OpenShift:
Beta Was this translation helpful? Give feedback.
All reactions