knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove Eventing Migration (#2898) 

- `ContainerSource` is still supported, so there is no migration to do.
- `CronJobSource` has been removed in 0.13.

Signed-off-by: Pierangelo Di Pilato <pierangelodipilato@gmail.com>
This commit is contained in:
Pierangelo Di Pilato 2020-10-07 16:40:21 +02:00 committed by GitHub
parent a5c233f793
commit 39e502def4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 0 additions and 182 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
docs/eventing/migration/README.md
View File

@ -1,6 +0,0 @@
Knative Eventing in version 0.13 does deprecate a few resources and
introduces new constructs for fine-grained control
over underlying resources.
This document provides a collection of such examples:
* [PingSource](./ping.md) migration from `CronJobSource`.
* [SinkBinding](./sinkbinding.md) alternative to `ContainerSource`.

8
docs/eventing/migration/_index.md
View File

@ -1,8 +0,0 @@
---
title: "Migration"
linkTitle: "Migration"
weight: 31
type: "docs"
---
{{% readfile file="README.md" %}}

47
docs/eventing/migration/ping.md
View File

@ -1,47 +0,0 @@
---
title: "Migrating from CronJobSource to the PingSource"
weight: 20
type: "docs"
aliases:
- /docs/eventing/ping.md
---
In 0.13, the deprecated `CronJobSource` should be converted to the `PingSource`.
The YAML file for a `CronJobSource` that emits events to a Knative Serving service will look similar to this:
```yaml
apiVersion: sources.knative.dev/v1alpha1
kind: CronJobSource
metadata:
name: cronjob-source
spec:
schedule: "* * * * *"
data: '{"message": "Hello world!"}'
sink:
apiVersion: serving.knative.dev/v1
kind: Service
name: event-display
```
To migrate this source to a `PingSource`, the following steps are required::
* Different `apiVersion` and `kind` between the two
* `PingSource` uses the `jsonData` attribute instead of the `data` attribute.
The updated YAML for `PingSource` will look similar to the following:
```yaml
apiVersion: sources.knative.dev/v1alpha2
kind: PingSource
metadata:
name: ping-source
spec:
schedule: "* * * * *"
jsonData: '{"message": "Hello world!"}'
sink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: event-display
```

121
docs/eventing/migration/sinkbinding.md
View File

@ -1,121 +0,0 @@
---
title: "SinkBinding alternative to ContainerSource"
weight: 20
type: "docs"
aliases:
- /docs/eventing/sinkbinding.md
---
`ContainerSource` can be seen as the combination of
`SinkBinding`+`Deployment`. In fact, that
is exactly how it's implemented!
In YAML, these two options are equivalent:
1. `ContainerSource` that emits events to a `Knative Service`:
```yaml
apiVersion: sources.knative.dev/v1beta1
kind: ContainerSource
metadata:
name: urbanobservatory-event-source
spec:
template:
spec:
containers:
- image: quay.io/openshift-knative/knative-eventing-sources-websocketsource:latest
args:
- '--source=wss://api.usb.urbanobservatory.ac.uk/stream'
- '--eventType=my.custom.event'
sink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: wss-event-display
```
2. `SinkBinding` + `Deployment`. Something like the following:
```yaml
apiVersion: sources.knative.dev/v1alpha2
kind: SinkBinding
metadata:
name: bind-wss
spec:
subject:
apiVersion: apps/v1
kind: Deployment
selector:
matchLabels:
app: wss
sink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: wss-event-display
```
Here the `SinkBinding`'s `subject` references to a Kubernetes
`Deployment`, that is labeled with `app: wss`. This is done with
the `subject.selector` field, which is a standard Kubernetes
Label Selector object. Note that you could explicitly set a
`Deployment` name and namespace in `subject` (i.e., `subject.name`
and `subject.namespace`) instead of using `subject.selector`.
The YAML for the `Deployment` looks like:
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: wss
labels:
app: wss
spec:
selector:
matchLabels:
app: wss
template:
metadata:
labels:
app: wss
spec:
containers:
- image: quay.io/openshift-knative/knative-eventing-sources-websocketsource:latest
name: wss
args:
- '--source=wss://api.usb.urbanobservatory.ac.uk/stream'
- '--eventType=my.custom.event'
```
The `Deployment` is a standard Kubernetes Deployment, like you might have used before. However, the important part
here is that it has the `app: wss` label, which is needed by the above `SinkBinding` in order to _bind_ the
two components together.
In both cases, the `image` is required to understand
the semantics of the `K_SINK` environment variable, which holds
the destination endpoint for sending CloudEvents.
Running any of the above examples will give a log similar to:
```
☁️ cloudevents.Event
Validation: valid
Context Attributes,
specversion: 1.0
type: my.custom.event
source: wss://api.usb.urbanobservatory.ac.uk/stream
id: 3029a2f2-3ce1-48c0-9ed3-37d7ad88d0ef
time: 2020-03-05T13:46:15.329595422Z
Data,
{"signal":2,"data":{"brokerage":{"broker":{"id":"BMS-USB-5-JACE","meta":{"protocol":"BACNET","building":"Urban Sciences Building","buildingFloor":"5"}},"id":"Drivers.L6_C3_Electric_Meters.C3_Mechcanical_Plant.points.C3_HP_Current_L1","meta":{}},"entity":{"name":"Urban Sciences Building: Floor 5","meta":{"building":"Urban Sciences Building","buildingFloor":"5"}},"feed":{"metric":"C3 HP Current L1","meta":{}},"timeseries":{"unit":"no units","value":{"time":"2020-03-05T13:45:51.468Z","timeAccuracy":8.754,"data":0.47110211849212646,"type":"Real"}}},"recipients":0}
```
## When to use SinkBinding?
From the above options, `ContainerSource` is probably the less
verbose.
However, the true power of `SinkBinding` comes from the fact that
it can work not just with `Deployments`
but with **any** PodSpecable (e.g., `StatefulSet`, `ReplicateSet`,
`DaemonSet`, `Knative Service`, etc.).
If you do need that flexibility, we highly recommend you to use `SinkBinding`.