Add docs / samples for Sequence (#1481)

* sequence with broker

* add sequence -> sequence sample

* sequence wired to event display

* terminal sequence

* first two examples moved to new v1beta1 services + cascading changes

* fix sequence2sequence to use v1beta services / default ns

* fix broker example to use v1beta1 service + default ns

* Address PR feedback

* add a pointer to vaikas-google/transformer sample

* update transformer image refs to latest

* address PR feedback

* move overview before prerequisites, add link to main sequence page
This commit is contained in:
Ville Aikas 2019-06-25 20:46:09 +03:00 committed by Knative Prow Robot
parent 80ab0ac297
commit c050da8bb5
26 changed files with 1462 additions and 0 deletions

View File

@ -0,0 +1,197 @@
---
title: "Sequence Wired to event-display"
weight: 20
type: "docs"
---
# Using Sequences in series
## Overview
We are going to create the following logical configuration. We create a CronJobSource,
feeding events to a (`Sequence`)[../../../sequence.md], then taking the output of that `Sequence` and
displaying the resulting output.
![Logical Configuration](./sequence-reply-to-event-display.png)
## Prerequisites
For this example, we'll assume you have set up an `InMemoryChannel`
as well as Knative Serving (for our functions). The examples use `default`
namespace, again, if you want to deploy to another Namespace, you will need
to modify the examples to reflect this.
If you want to use different type of `Channel`, you will have to modify the
`Sequence.Spec.ChannelTemplate` to create the appropriate Channel resources.
## Setup
### Create the Knative Services
Change `default` below to create the steps in the Namespace where you want resources
created.
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---
```
```shell
kubectl -n default create -f ./steps.yaml
```
### Create the Sequence
The `sequence.yaml` file contains the specifications for creating the Sequence. If you are using a different type of Channel, you need to change the
spec.channelTemplate to point to your desired Channel.
```yaml
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Service
apiVersion: serving.knative.dev/v1beta1
name: event-display
```
Change `default` below to create the `Sequence` in the Namespace where you want the
resources to be created.
```shell
kubectl -n default create -f ./sequence.yaml
```
### Create the Service displaying the events created by Sequence
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: event-display
spec:
template:
spec:
containers:
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
```
Change `default` below to create the `Sequence` in the Namespace where you want your resources
to be created.
```shell
kubectl -n default create -f ./event-display.yaml
```
### Create the CronJobSource targeting the Sequence
This will create a CronJobSource which will send a CloudEvent with {"message": "Hello world!"} as
the data payload every 2 minutes.
```yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence
```
```shell
kubectl -n default create -f ./cron-source.yaml
```
### Inspecting the results
You can now see the final output by inspecting the logs of the event-display pods.
```shell
kubectl -n default get pods
```
Then look at the logs for the event-display pod:
```shell
kubectl -n default logs -l serving.knative.dev/service=event-display -c user-container
☁️ cloudevents.Event
Validation: valid
Context Attributes,
cloudEventsVersion: 0.1
eventType: samples.http.mod3
source: /transformer/2
eventID: df52b47e-02fd-45b2-8180-dabb572573f5
eventTime: 2019-06-18T14:18:42.478140635Z
contentType: application/json
Data,
{
"id": 0,
"message": "Hello world! - Handled by 0 - Handled by 1 - Handled by 2"
}
```
And you can see that the initial Cron Source message ("Hello World!") has been appended to it by each
of the steps in the Sequence.

View File

@ -0,0 +1,11 @@
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence

View File

@ -0,0 +1,9 @@
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: event-display
spec:
template:
spec:
containers:
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

View File

@ -0,0 +1,25 @@
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Service
apiVersion: serving.knative.dev/v1beta1
name: event-display

View File

@ -0,0 +1,40 @@
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---

View File

@ -0,0 +1,271 @@
---
title: "Sequence Wired to another Sequence"
weight: 20
type: "docs"
---
# Using Sequences in series
## Overview
We are going to create the following logical configuration. We create a CronJobSource,
feeding events to a (`Sequence`)[../../../sequence.md], then taking the output of that `Sequence` and sending
it to a second `Sequence` and finally displaying the resulting output.
![Logical Configuration](./sequence-reply-to-sequence.png)
## Prerequisites
For this example, we'll assume you have set up a an `InMemoryChannel`
as well as Knative Serving (for our functions). The examples use `default`
namespace, again, if you want to deploy to another Namespace, you will need to
modify the examples to reflect this.
If you want to use different type of `Channel`, you will have to modify the
`Sequence.Spec.ChannelTemplate` to create the appropriate Channel resources.
## Setup
### Create the Knative Services
Change `default` below to create the steps in the Namespace where you want resources
created.
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: fourth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "3"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: fifth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "4"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: sixth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "5"
---
```
```shell
kubectl -n default create -f ./steps.yaml
```
### Create the first Sequence
The `sequence1.yaml` file contains the specifications for creating the Sequence. If you are using a different type of
Channel, you need to change the spec.channelTemplate to point to your desired Channel.
```yaml
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: first-sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Sequence
apiVersion: messaging.knative.dev/v1alpha1
name: second-sequence
```
Change `default` below to create the `Sequence` in the Namespace where you want
your resources created.
```shell
kubectl -n default create -f ./sequence1.yaml
```
### Create the second Sequence
The `sequence2.yaml` file contains the specifications for creating the Sequence. If you are using a different type of
Channel, you need to change the spec.channelTemplate to point to your desired Channel.
```yaml
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: second-sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: fourth
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: fifth
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: sixth
reply:
kind: Service
apiVersion: serving.knative.dev/v1beta1
name: event-display
```
### Create the Service displaying the events created by Sequence
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: event-display
spec:
template:
spec:
containerers:
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
```
Change `default` below to create the `Sequence` in the Namespace where you want your resources
created.
```shell
kubectl -n default create -f ./event-display.yaml
```
### Create the CronJobSource targeting the first Sequence
This will create a CronJobSource which will send a CloudEvent with {"message": "Hello world!"} as
the data payload every 2 minutes.
```yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: first-sequence
```
```shell
kubectl -n default create -f ./cron-source.yaml
```
### Inspecting the results
You can now see the final output by inspecting the logs of the event-display pods.
```shell
kubectl -n default get pods
```
Then look at the logs for the event-display pod:
```shell
kubectl -n default logs -l serving.knative.dev/service=event-display -c user-container
☁️ cloudevents.Event
Validation: valid
Context Attributes,
cloudEventsVersion: 0.1
eventType: samples.http.mod3
source: /transformer/5
eventID: 7628a147-ec74-43d5-a888-8384a1b6b005
eventTime: 2019-06-18T13:57:20.279354375Z
contentType: application/json
Data,
{
"id": 0,
"message": "Hello world! - Handled by 0 - Handled by 1 - Handled by 2 - Handled by 3 - Handled by 4 - Handled by 5"
}
```
And you can see that the initial Cron Source message ("Hello World!") has been appended to it by each
of the steps in the Sequence.

View File

@ -0,0 +1,11 @@
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: first-sequence

View File

@ -0,0 +1,9 @@
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: event-display
spec:
template:
spec:
containers:
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display

Binary file not shown.

After

Width:  |  Height:  |  Size: 17 KiB

View File

@ -0,0 +1,25 @@
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: first-sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Sequence
apiVersion: messaging.knative.dev/v1alpha1
name: second-sequence

View File

@ -0,0 +1,25 @@
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: second-sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: fourth
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: fifth
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: sixth
reply:
kind: Service
apiVersion: serving.knative.dev/v1alpha1
name: event-display

View File

@ -0,0 +1,80 @@
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: fourth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "3"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: fifth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "4"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: sixth
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "5"
---

View File

@ -0,0 +1,257 @@
title: "Sequence terminal"
weight: 20
type: "docs"
---
# Using Sequences in series
## Overview
We are going to create the following logical configuration. We create a CronJobSource,
feeding events to a (`Sequence`)[../../../sequence.md]. Sequence can then do either external work, or
out of band create additional events.
![Logical Configuration](./sequence-terminal.png)
## Prerequisites
For this example, we'll assume you have set up an `InMemoryChannel`
as well as Knative Serving (for our functions). The examples use `default`
namespace, again, if you want to deploy to another Namespace, you will need
to modify the examples to reflect this.
If you want to use different type of `Channel`, you will have to modify the
`Sequence.Spec.ChannelTemplate` to create the appropriate Channel resources.
## Setup
### Create the Knative Services
First create the 3 steps that will be referenced in the Steps.
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---
```
```shell
kubectl -n default create -f ./steps.yaml
```
### Create the Sequence
The `sequence.yaml` file contains the specifications for creating the Sequence. If you are using a different type of Channel, you need to change the
spec.channelTemplate to point to your desired Channel.
```yaml
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
```
Change `default` below to create the `Sequence` in the Namespace where you want the
resources to be created.
```shell
kubectl -n default create -f ./sequence.yaml
```
### Create the CronJobSource targeting the Sequence
This will create a CronJobSource which will send a CloudEvent with {"message": "Hello world!"} as
the data payload every 2 minutes.
```yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence
```
Here, if you are using different type of Channel, you need to change the
spec.channelTemplate to point to your desired Channel.
```shell
kubectl -n default create -f ./cron-source.yaml
```
### Inspecting the results
You can now see the final output by inspecting the logs of the event-display pods. Note that since
we set the `CronJobSource` to emit every 2 minutes, it might take some time for the events to show
up in the logs.
```shell
kubectl -n default get pods
```
Let's look at the logs for the first `Step` in the `Sequence`:
```shell
kubectl -n default logs -l serving.knative.dev/service=first -c user-container
Got Event Context: Context Attributes,
specversion: 0.2
type: dev.knative.cronjob.event
source: /apis/v1/namespaces/default/cronjobsources/cronjob-source
id: 2fdf69ec-0480-463a-92fb-8d1259550f32
time: 2019-06-18T14:38:00.000379084Z
contenttype: application/json
Extensions,
knativehistory: sequence-kn-sequence-0-kn-channel.default.svc.cluster.local
2019/06/18 14:38:14 http: superfluous response.WriteHeader call from github.com/vaikas-google/transformer/vendor/github.com/cloudevents/sdk-go/pkg/cloudevents/transport/http.(*Transport).ServeHTTP (transport.go:446)
Got Data: &{Sequence:0 Message:Hello world!}
Got Transport Context: Transport Context,
URI: /
Host: first.default.svc.cluster.local
Method: POST
Header:
X-Request-Id: 9b51bcaa-10bc-97a5-a288-dde9b97f6e1e
Content-Length: 26
K-Proxy-Request: activator
X-Forwarded-For: 10.16.3.77, 127.0.0.1, 127.0.0.1
X-Forwarded-Proto: http
Ce-Knativehistory: sequence-kn-sequence-0-kn-channel.default.svc.cluster.local
X-B3-Spanid: 42bcd58bd1ea8191
X-B3-Parentspanid: c63efd989dcf5dc5
X-B3-Sampled: 0
X-B3-Traceid: 4a1da6622ecbbdea0c75ae32e065cfcb
----------------------------
```
Then we can look at the output of the second Step in the `Sequence`:
```shell
kubectl -n default logs -l serving.knative.dev/service=second -c user-container
Got Event Context: Context Attributes,
cloudEventsVersion: 0.1
eventType: samples.http.mod3
source: /transformer/0
eventID: 5a9ec173-5224-41a2-9c83-50786651bcd5
eventTime: 2019-06-18T14:38:14.657008072Z
contentType: application/json
Got Data: &{Sequence:0 Message:Hello world! - Handled by 0}
Got Transport Context: Transport Context,
URI: /
Host: second.default.svc.cluster.local
Method: POST
Header:
X-Forwarded-For: 10.16.3.77, 127.0.0.1, 127.0.0.1
X-Forwarded-Proto: http
Content-Length: 48
X-B3-Sampled: 0
Ce-Knativehistory: sequence-kn-sequence-1-kn-channel.default.svc.cluster.local
X-B3-Parentspanid: 4fba491a605b2391
K-Proxy-Request: activator
X-B3-Spanid: 56e4150c4e1d679b
X-B3-Traceid: fb468aa8ec035a66153ce3f4929aa2fe
X-Request-Id: d60e7109-3853-9ca1-83e2-c70f8cbfbb93
----------------------------
```
And you can see that the initial Cron Source message ("Hello World!") has now been modified by the
first step in the Sequence to include " - Handled by 0". Exciting :)
Then we can look at the output of the last Step in the `Sequence`:
```shell
kubectl -n default logs -l serving.knative.dev/service=third -c user-container
Got Event Context: Context Attributes,
cloudEventsVersion: 0.1
eventType: samples.http.mod3
source: /transformer/1
eventID: 5747fb77-66a2-4e78-944b-43192aa879fb
eventTime: 2019-06-18T14:38:32.688345694Z
contentType: application/json
Got Data: &{Sequence:0 Message:Hello world! - Handled by 0 - Handled by 1}
Got Transport Context: Transport Context,
URI: /
Host: third.default.svc.cluster.local
Method: POST
Header:
X-B3-Sampled: 0
X-B3-Traceid: 64a9c48c219375476ffcdd5eb14ec6e0
X-Forwarded-For: 10.16.3.77, 127.0.0.1, 127.0.0.1
X-Forwarded-Proto: http
Ce-Knativehistory: sequence-kn-sequence-2-kn-channel.default.svc.cluster.local
K-Proxy-Request: activator
X-Request-Id: 505ff620-2822-9e7d-8855-53d02a2e36e2
Content-Length: 63
X-B3-Parentspanid: 9e822f378ead293c
X-B3-Spanid: a56ee81909c767e6
----------------------------
```
And as expected it's now been handled by both the first and second Step as reflected by
the Message being now: "Hello world! - Handled by 0 - Handled by 1"

View File

@ -0,0 +1,11 @@
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

View File

@ -0,0 +1,21 @@
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third

View File

@ -0,0 +1,40 @@
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---

View File

@ -0,0 +1,227 @@
---
title: "Sequence with Broker and Trigger"
weight: 20
type: "docs"
---
# Using Sequence with Broker and Trigger
## Overview
We are going to create the following logical configuration. We create a CronJobSource,
feeding events into the Broker, then we create a `Filter` that wires those events
into a (`Sequence`)[../../../sequence.md] consisting of 3 steps. Then we take the end of the Sequence and
feed newly minted events back into the Broker and create another Trigger which
will then display those events.
**NOTE** [TODO: Fix this](https://github.com/knative/eventing/issues/1421)
So, currently as set up, the events emitted by the Sequence do not make it into
the Broker.
## Prerequisites
For this example, we'll assume you have set up a `Broker` and an `InMemoryChannel`
as well as Knative Serving (for our functions). The examples use `default`
namespace, again, if your broker lives in another Namespace, you will need to
modify the examples to reflect this.
If you want to use different type of `Channel`, you will have to modify the
`Sequence.Spec.ChannelTemplate` to create the appropriate Channel resources.
![Logical Configuration](./sequence-with-broker-trigger.png)
## Setup
### Create the Knative Services
Change `default` below to create the steps in the Namespace where you have configured your
`Broker`
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---
```
```shell
kubectl -n default create -f ./steps.yaml
```
### Create the Sequence
The `sequence.yaml` file contains the specifications for creating the Sequence. If you are using a different type of Channel,
you need to change the spec.channelTemplate to point to your desired Channel.
Also, change the spec.reply.name to point to your `Broker`
```yaml
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Broker
apiVersion: eventing.knative.dev/v1alpha1
name: broker-test
```
Change `default` below to create the `Sequence` in the Namespace where you have configured your
`Broker`.
```shell
kubectl -n default create -f ./sequence.yaml
```
### Create the CronJobSource targeting the Broker
This will create a CronJobSource which will send a CloudEvent with {"message": "Hello world!"} as
the data payload every 2 minutes.
```yaml
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
name: broker-test
```
Here, if you are using different type of Channel, you need to change the
spec.channelTemplate to point to your desired Channel. Also, change the
spec.reply.name to point to your `Broker`
Change `default` below to create the `Sequence` in the Namespace where you have configured your
`Broker`.
```shell
kubectl -n default create -f ./cron-source.yaml
```
### Create the Trigger targeting the Sequence
```yaml
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: sequence-trigger
spec:
filter:
sourceAndType:
type: dev.knative.cronjob.event
subscriber:
ref:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence
```
Change `default` below to create the `Sequence` in the Namespace where you have configured your
`Broker`.
```shell
kubectl -n default create -f ./trigger.yaml
```
### Create the Service and Trigger displaying the events created by Sequence
**NOTE** This does not work yet because the events created by the Sequence in the last step
are filtered. [TODO: Fix this](https://github.com/knative/eventing/issues/1421)
```yaml
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: sequence-display
spec:
template:
spec:
containers:
- image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
---
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: sequence-trigger
spec:
filter:
sourceAndType:
type: samples.http.mod3
subscriber:
ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: sequence-display
---
```
Change `default` below to create the `Sequence` in the Namespace where you have configured your
`Broker`.
```shell
kubectl -n default create -f ./display-trigger.yaml
```

View File

@ -0,0 +1,11 @@
apiVersion: sources.eventing.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "*/2 * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: eventing.knative.dev/v1alpha1
kind: Broker
name: broker-test

View File

@ -0,0 +1,27 @@
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: sequence-display
spec:
runLatest:
configuration:
revisionTemplate:
spec:
container:
image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display
---
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: display-trigger
spec:
broker: broker-test
filter:
sourceAndType:
type: samples.http.mod3
subscriber:
ref:
apiVersion: serving.knative.dev/v1alpha1
kind: Service
name: sequence-display
---

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

View File

@ -0,0 +1,25 @@
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
metadata:
name: sequence
spec:
channelTemplate:
apiVersion: messaging.knative.dev/v1alpha1
kind: InMemoryChannel
steps:
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: first
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: second
- ref:
apiVersion: serving.knative.dev/v1beta1
kind: Service
name: third
reply:
kind: Broker
apiVersion: eventing.knative.dev/v1alpha1
name: broker-test

View File

@ -0,0 +1,41 @@
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: first
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "0"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: second
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "1"
---
apiVersion: serving.knative.dev/v1beta1
kind: Service
metadata:
name: third
spec:
template:
spec:
containers:
- image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700
env:
- name: STEP
value: "2"
---

View File

@ -0,0 +1,14 @@
apiVersion: eventing.knative.dev/v1alpha1
kind: Trigger
metadata:
name: sequence-trigger
spec:
broker: broker-test
filter:
sourceAndType:
type: dev.knative.cronjob.event
subscriber:
ref:
apiVersion: messaging.knative.dev/v1alpha1
kind: Sequence
name: sequence

85
docs/eventing/sequence.md Normal file
View File

@ -0,0 +1,85 @@
---
title: "Sequence"
weight: 20
type: "docs"
---
Sequence CRD provides a way to define an in-order list of functions that will
be invoked. Each step can modify, filter or create a new kind of an event.
Sequence creates `Channel`s and `Subscription`s under the hood.
## Usage
### Sequence Spec
Sequence has three parts for the Spec:
1. `Steps` which defines the in-order list of `Subscriber`s, aka, which functions
are executed in the listed order. These are specified using the
`eventingv1alpha1.SubscriberSpec` just like you would when creating `Subscription`.
Each step should be `Callable`.
1. `ChannelTemplate` defines the Template which will be used to create `Channel`s
between the steps.
1. `Reply` (Optional) Reference to where the results of the final step in the
sequence are sent to.
### Sequence Status
Sequence has four parts for the Status:
1. Conditions which detail the overall Status of the Sequence object
1. ChannelStatuses which convey the Status of underlying `Channel` resources that
are created as part of this Sequence. It is an array and each Status corresponds to the Step number,
so the first entry in the array is the Status of the `Channel` before the first Step.
1. SubscriptionStatuses which convey the Status of underlying `Subscription` resources that
are created as part of this Sequence. It is an array and each Status corresponds to the Step number, so
the first entry in the array is the `Subscription` which is created to wire the first channel to the
first step in the `Steps` array.
1. AddressStatus which is exposed so that Sequence can be used where Addressable can be used. Sending
to this address will target the `Channel` which is fronting the first Step in the Sequence.
## Examples
For each of these examples below, we'll use
[`CronJobSource`](https://knative.dev/docs/eventing/samples/cronjob-source/)
as the source of events.
We also use a very simple [transformer](https://github.com/vaikas-google/transformer) which
performs very trivial transformation of the incoming events to demonstrate they have passed
through each stage.
### (Sequence with no reply (terminal last Step))[./samples/sequence/sequence-terminal/README.md)
For the first example, we'll use a 3 Step `Sequence` that is wired directly into the `CronJobSource`.
Each of the steps simply tacks on "- Handled by <STEP NUMBER>", for example the first Step in the
`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message.
### [Sequence with reply (last Step produces output)](./samples/sequence/sequence-reply-to-event-display/README.md)
For the next example, we'll use the same 3 Step `Sequence` that is wired directly into the `CronJobSource`.
Each of the steps simply tacks on "- Handled by <STEP NUMBER>", for example the first Step in the
`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message.
The only difference is that we'll use the `Subscriber.Spec.Reply` field to wire the output of the
last Step to an event display pod.
### [Chaining Sequences together](./samples/sequence/sequence-reply-to-sequence/README.md)
For the next example, we'll use the same 3 Step `Sequence` that is wired directly into the `CronJobSource`.
Each of the steps simply tacks on "- Handled by <STEP NUMBER>", for example the first Step in the
`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message.
The only difference is that we'll use the `Subscriber.Spec.Reply` field to wire the output of the
last Step to another `Sequence` that does the smae message modifications as the first pipeline (with
different steps however).
### [Using Sequence with Broker/Trigger model](./samples/sequence/sequence-with-broker-trigger/README.md)
You can also create a Trigger which targets `Sequence`. This time we'll wire `CronJobSource` to send
events to a `Broker` and then we'll have the `Sequence` emit the resulting Events back into the Broker
so that the results of the `Sequence` can be observed by other `Trigger`s.