-
Enhancement
-
Resolution: Done
-
Major
-
1.14.0.Final
-
None
-
False
-
False
-
Documentation (Ref Guide, User Guide, etc.)
-
-
2021 Week 46-48 (from Nov 15), 2021 Week 49-51 (from Dec 6th)
Currently, for a user to deploy an SW service as a Knative Service on a local or dev environment, they must first build the project's image, push to a public registry and then manually create the Kservice.
Kogito already provides a way to interact with the Knative Eventing platform through our add-on. The idea here is to leverage this add-on to integrate with the Quarkus Kubernetes and Knative extension to automatically deploy the SW service on Knative. Ideally for local development only. Complex scenarios should leverage more robust tooling such as Tekton, Jenkins, or OpenShift Pipelines. Although our approach should work fine for production environments as well.
If the target Kogito Service also produces an event, the extension would generate a specific KogitoSource custom resource to bind the service with the Knative Eventing platform.
The target sink can be configured via properties, for example:
org.kie.kogito.knative.eventing.sink.apiVersion=messaging.knative.dev/v1
org.kie.kogito.knative.eventing.sink.kind=InMemoryChannel
org.kie.kogito.knative.eventing.sink.name=in-memory-channel
org.kie.kogito.knative.eventing.sink.namespace=default
If not provided, the above properties must be used to sink the event somewhere. The subject of the source is obviously the current project.
Note that the KogitoSource generation should only be executed if the quarkus-kubernetes extension is enabled in the project.
The KogitoSource generation also should be disabled by default in favor of a generated SinkBinding. Users must opt in to generate the source instead since it will require the source installation. On clusters without admin rights, it will make it difficult to integrate. To enable the kogitosource generation instead:
org.kie.kogito.knative.eventing.kogitoSource.enabled=true
- relates to
-
KOGITO-6047 Make Knative Kogito source bind to a Podspec-able resource instead of KogitoRuntime
- Resolved