Inheriting features from the Runtime Component Operator

[arthurdm]

Hi guys. I am from the team that developed the Appsody Operator and Open Liberty Operator.

We have recently refactored the common code to create the Runtime Component Operator, capable of deploying any runtime as well as being imported (at the Go code level) as a library to enhance existing operators.

That's the approach we took to enhance both the Appsody and Open Liberty operators. This allowed us to focus on runtime-specific features, for example in Open Liberty we have the day-2 operations for setting/unsetting trace and for getting a JVM dump. This means that any functionality that goes into the generic Application Runtimes can be leveraged by the extending operators - creating consistency and moving everyone up at the same time.

Check out its capabilities and see if perhaps the Wildfly operator would like to also benefit from importing this library. We are currently adding other cool features such as integration with OpenShift's Certificate Manager and application -> resource binding via RH's Service Binding Operator (we already do application <-> application binding natively). We're aiming to reach maturity level 5 (Auto Pilot) with this set of features.

That means the Runtime Component repo becomes a central community where folks developing runtime operators (such as Wildfly, Open Liberty, etc) can contribute to and everyone benefits.

[arthurdm]

hey @jmesnil - just wanted to give an update on this. We have renamed this operator to Runtime Component Operator and have published it into Operator Hub's community repo as a maturity 5 operator.

This mean that Open Liberty's Operator will also be at maturity 5 in about 2 weeks once we update it with the Runtime Component libraries. Could do the same for Wildfly / JBoss. 😃