Skip to content

Commit

Permalink
doc for knative eventing in operator
Browse files Browse the repository at this point in the history
  • Loading branch information
RichardW98 committed Mar 11, 2024
1 parent 3c656b7 commit b64e1ba
Show file tree
Hide file tree
Showing 2 changed files with 60 additions and 0 deletions.
1 change: 1 addition & 0 deletions serverlessworkflow/modules/ROOT/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -74,6 +74,7 @@
*** xref:cloud/operator/building-custom-images.adoc[Building Custom Images]
*** xref:cloud/operator/customize-podspec.adoc[Custom Workflow PodSpec]
*** xref:cloud/operator/service-discovery.adoc[Service Discovery]
*** xref:cloud/operator/configuring-knative-eventing-resources.adoc[Knative Eventing]
*** xref:cloud/operator/known-issues.adoc[Roadmap and Known Issues]
* Integrations
** xref:integrations/core-concepts.adoc[]
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
= Knative Eventing
:compat-mode!:
// Metadata:
:description: Configuration of knatve eventing deployed by the operator
:keywords: kogito, sonataflow, workflow, serverless, operator, kubernetes, knative, knative-eventing, events

This document describes how you can configure the workflows to let operator create the knative eventing resources on Kubernetes.

{operator_name} can analyze the event definitions from the `spec.flow` and create `SinkBinding`/`Trigger` based on the type of the event. Then the workflow service can utilize them for event communications. The same purpose of this feature in quarkus extension can be found xref:use-cases/advanced-developer-use-cases/event-orchestration/consume-produce-events-with-knative-eventing.adoc#ref-example-sw-event-definition-knative[here].

== Prerequisite
1. Knative is installed on the cluster and Knative Eventing is initiated with a `KnativeEventing` CR.
2. a broker named `default` is created. Currently all Triggers created by the {operator_name} will read events from `default`

== Configuring the workflow

For the operator to create the `SinkBinding` resources, the workflow must provide the sink information in `spec.sink`.

.Example of a workflow with events
[source,yaml,subs="attributes+"]
--
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
...
spec:
sink:
ref: <1>
name: default
namespace: greeting
apiVersion: eventing.knative.dev/v1
kind: Broker
flow:
events: <2>
- name: requestQuote
type: kogito.sw.request.quote
kind: produced
- name: aggregatedQuotesResponse,
type: kogito.loanbroker.aggregated.quotes.response,
kind: consumed,
source: /kogito/serverless/loanbroker/aggregator
...
--
<1> `spec.sink.ref` defines the sink that all created sinkBinding will use as the destination sink for producing events
<2> `spec.flow.events` lists all the events referenced in the workflow. Events with `produced` kind will trigger the creation of `SinkBindings` by the {operator_name}, while those labeled as `consumed` will lead to the generation of `Triggers`.

[NOTE]
====
Knative resources is not watched by the operator, indicating that they won't undergo automatic reconciliation. This grants users the freedom to make updates at their discretion.
====

== Additional resources

* https://knative.dev/docs/eventing/[Knative Eventing official site]
* xref:use-cases/advanced-developer-use-cases/event-orchestration/consume-produce-events-with-knative-eventing.adoc[quarkus extension for knative eventing]
* xref:job-services/core-concepts.adoc#knative-eventing-supporting-resources[knative eventing for Job service]
* xref:data-index/data-index-core-concepts.adoc#_knative_eventing[knative eventing for data index]

include::../../../pages/_common-content/report-issue.adoc[]

0 comments on commit b64e1ba

Please sign in to comment.