Consider offer a Kubernetes operator for Quarkus applications

[emmanuelbernard]

A operator could update the application based on new framework minor or even micro changes based on policy (only micro, automated vs manual etc). This would be based on the ability for Quarkus to have a provisioning phase.

Also an operator can reload the application based on ConfigMap change. If the ConfigMap changes have a build time property, have a policy to force a recompilation for redeployment or a warning. An operator would be preferable than embedding this logic in the application itself for "automated restart" and more inline with Quarkus philosophy.

Something to do on the quarkus:dev mode with the operator?

Some more ideas can be taken from the Snowdrop team effort https://github.com/snowdrop/component-operator

[cmoulliard]

Some more ideas can be taken from the Snowdrop team effort

Our operator could be easily extended to support Quarkus as we already can deploy SpringBoot, Vert.x, Thorntail or even NodeJS if we use s2i. More images / deployment modes should be supported in the future

[gastaldi]

Also an operator can reload the application based on ConfigMap change.

This is a feature that https://github.com/fabric8io/configmapcontroller does really well, perhaps use that instead?

[machi1990]

What's the plan on this one? I am really curios about it @emmanuelbernard @cmoulliard

[maxandersen]

I've opened a proposal for epic on making it easy to use quarkus for configuring and writing a kubernetes native operator - slightly different scope than this; but should definitely consider the same capabilties of updating etc.

[geoand]

It makes sense to mention that such an operator could now be written in Quarkus due to the existence of https://github.com/quarkiverse/quarkus-operator-sdk

cc @metacosm