Right now, Kogito Operator is creating a ConfigMap with application.properties file and mounting it as a volume in the Deployment resource.

Users can then edit this ConfigMap and add their own information in there. The problem is that this can only happen after the application is deployed, which won't make sense in some scenarios like configuring a persistence storage upfront.

Kogito Operator should acknowledge ConfigMaps created upfront from users and mount them instead. This way, on a CI/CD process, users would create their ConfigMap upfront, create the KogitoService instance and the operator would bind them together. The service will be deployed with the correct configuration from start.

The operator would them manage this ConfigMap as one of the owners, and in case of a deletion, the standard ConfigMap would then be created.

if no ConfigMap is provided, we continue to create one like we are doing today.

Proposed CR:

apiVersion: app.kiegroup.org/v1alpha1
kind: KogitoRuntime
metadata:
  name: process-quarkus-example
spec:
  replicas: 1
  configMap: my-cm-properties
  image:
    domain: quay.io
    namespace: kiegroup
    name: process-quarkus-example

If no application.properties key is found in the ConfigMap, one must be created.

This configuration should work for Quarkus and SpringBoot runtimes.