Today, the operator deploys a custom Kogito service via a regular Kubernetes Deployment. The goal of this JIRA is to add a limited support for serverless deployments of custom Kogito Services.

This is what a regular KogitoRuntime looks like:

apiVersion: app.kiegroup.org/v1beta1
kind: KogitoRuntime
metadata:
  name: process-quarkus-example
spec:
  replicas: 1
  image: quay.io/kiegroup/process-quarkus-example

A suggestion to add to this interface is something like:

apiVersion: app.kiegroup.org/v1beta1
kind: KogitoRuntime
metadata:
  name: process-quarkus-example
spec:
  replicas: 1
  image: quay.io/kiegroup/process-quarkus-example
  deploymentMode: knative

Having deploymentMode set to knative will make the operator to create a valid Knative Service instead of a regular Kubernetes Deployment, for example:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: process-quarkus-example
spec:
  template:
    spec:
      containers:
        - image: quay.io/kiegroup/process-quarkus-example

To make this work, the operator should warn the user if the Knative platform is not installed in the cluster, thus making this deployment not possible. A message in the status portion of the KogitoRuntime should describe the actual state of this deployment as we have today for regular k8s deployments.

When we say "limited", it means that we will (1) verify if knative is installed to update the status accordingly, and (2) deploy as a Knative service and manage the deployment as any other regular deployments.

Further features must be handled in future JIRAS, but this is a start point for a simple demo with OptaPlanner use case.