mirror of https://github.com/knative/docs.git
v1alpha1 -> v1beta1 (#2561)
* v1alpha1 -> v1beta1 * fix links, cronjobsource->pingsource
This commit is contained in:
parent
9db70796af
commit
8dcca2764d
|
@ -113,11 +113,11 @@ the event destination.
|
|||
|
||||
Knative Eventing also defines an event forwarding and persistence layer, called
|
||||
a
|
||||
[**Channel**](https://github.com/knative/eventing/blob/master/pkg/apis/messaging/v1alpha1/channel_types.go#L57).
|
||||
[**Channel**](https://github.com/knative/eventing/blob/master/pkg/apis/messaging/v1beta1/channel_types.go#L57).
|
||||
Each channel is a separate Kubernetes [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
Events are delivered to Services or forwarded to other channels
|
||||
(possibly of a different type) using
|
||||
[Subscriptions](https://github.com/knative/eventing/blob/master/pkg/apis/messaging/v1alpha1/subscription_types.go).
|
||||
[Subscriptions](https://github.com/knative/eventing/blob/master/pkg/apis/messaging/v1beta1/subscription_types.go).
|
||||
This allows message delivery in a cluster to vary based on requirements, so that
|
||||
some events might be handled by an in-memory implementation while others would
|
||||
be persisted using Apache Kafka or NATS Streaming.
|
||||
|
@ -165,7 +165,7 @@ If you need a Source not covered by the ones mentioned below nor by the other
|
|||
|
||||
If your code needs to send events as part of its business logic and doesn't fit
|
||||
the model of a Source, consider
|
||||
[feeding events directly to a Broker](https://knative.dev/docs/eventing/broker-trigger/#manual).
|
||||
[feeding events directly to a Broker](https://knative.dev/docs/eventing/broker/).
|
||||
|
||||
### Core Sources
|
||||
|
||||
|
|
|
@ -253,7 +253,7 @@ spec:
|
|||
sink:
|
||||
ref:
|
||||
# Deliver events to Broker.
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
```
|
||||
|
|
|
@ -186,7 +186,7 @@ kubectl --namespace knative-debug get apiserversource src -o jsonpath='{.spec.si
|
|||
```
|
||||
|
||||
Which should return
|
||||
`map[apiVersion:messaging.knative.dev/v1alpha1 kind:Channel name:chan]`. If it
|
||||
`map[apiVersion:messaging.knative.dev/v1beta1 kind:Channel name:chan]`. If it
|
||||
doesn't, then `src` was setup incorrectly and its `spec` needs to be fixed.
|
||||
Fixing should be as simple as updating its `spec` to have the correct `sink`
|
||||
(see [example.yaml](example.yaml)).
|
||||
|
|
|
@ -24,7 +24,7 @@ spec:
|
|||
kind: Event
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: chan
|
||||
|
||||
|
@ -32,7 +32,7 @@ spec:
|
|||
|
||||
# The Channel events are sent to.
|
||||
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
metadata:
|
||||
name: chan
|
||||
|
@ -41,14 +41,14 @@ metadata:
|
|||
|
||||
# The Subscription to the InMemoryChannel.
|
||||
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: sub
|
||||
namespace: knative-debug
|
||||
spec:
|
||||
channel:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: chan
|
||||
subscriber:
|
||||
|
|
|
@ -13,7 +13,7 @@ type's information in the cluster's data store.
|
|||
|
||||
## Before you begin
|
||||
|
||||
1. Read about the [Broker and Trigger objects](./broker-trigger.md).
|
||||
1. Read about the [Broker and Trigger objects](./broker/).
|
||||
1. Be familiar with the
|
||||
[CloudEvents spec](https://github.com/cloudevents/spec/blob/master/spec.md),
|
||||
particularly the
|
||||
|
@ -55,7 +55,7 @@ looks like:
|
|||
Omitting irrelevant fields:
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: EventType
|
||||
metadata:
|
||||
name: dev.knative.source.github.push-34cnb
|
||||
|
@ -120,7 +120,7 @@ Here are a few example Triggers that subscribe to events using exact matching on
|
|||
1. Subscribes to GitHub _pushes_ from any source.
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: push-trigger
|
||||
|
@ -145,7 +145,7 @@ Here are a few example Triggers that subscribe to events using exact matching on
|
|||
1. Subscribes to GitHub _pull requests_ from _knative's eventing_ repository.
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: gh-knative-eventing-pull-trigger
|
||||
|
@ -166,7 +166,7 @@ Here are a few example Triggers that subscribe to events using exact matching on
|
|||
1. Subscribes to Kafka messages sent to the _knative-demo_ topic
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: kafka-knative-demo-trigger
|
||||
|
@ -188,7 +188,7 @@ Here are a few example Triggers that subscribe to events using exact matching on
|
|||
_testing_ topic
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: gcp-pubsub-knative-testing-trigger
|
||||
|
@ -251,7 +251,7 @@ the next topic: How do we actually populate the registry in the first place?
|
|||
bootstrapServers: my-cluster-kafka-bootstrap.kafka:9092
|
||||
topics: knative-demo,news
|
||||
sink:
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
```
|
||||
|
|
|
@ -18,7 +18,7 @@ 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
|
||||
`messaging.v1beta1.SubscriberSpec` just like you would when creating
|
||||
`Subscription`. Each step should be `Addressable`.
|
||||
1. `ChannelTemplate` defines the Template which will be used to create
|
||||
`Channel`s between the steps.
|
||||
|
@ -46,7 +46,7 @@ Sequence has four parts for the Status:
|
|||
## Examples
|
||||
|
||||
For each of these examples below, we'll use
|
||||
[`CronJobSource`](https://knative.dev/docs/eventing/samples/cronjob-source/) as
|
||||
[`PingSource`](https://knative.dev/docs/eventing/samples/ping-source/) as
|
||||
the source of events.
|
||||
|
||||
We also use a very simple
|
||||
|
@ -57,14 +57,14 @@ 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
|
||||
the `PingSource`. 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
|
||||
directly into the `PingSource`. 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.
|
||||
|
||||
|
@ -74,7 +74,7 @@ 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
|
||||
directly into the `PingSource`. 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.
|
||||
|
||||
|
@ -85,6 +85,6 @@ 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`
|
||||
`PingSource` 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.
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Channel for testing events.
|
||||
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
metadata:
|
||||
name: camel-test
|
||||
|
@ -9,13 +9,13 @@ metadata:
|
|||
|
||||
# Subscription from the CamelSource's output Channel to the Knative Service below.
|
||||
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: Subscription
|
||||
metadata:
|
||||
name: camel-source-display
|
||||
spec:
|
||||
channel:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: camel-test
|
||||
subscriber:
|
||||
|
|
|
@ -21,6 +21,6 @@ spec:
|
|||
constant: application/json
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: camel-test
|
||||
|
|
|
@ -27,6 +27,6 @@ spec:
|
|||
message: "Forwarding: ${body}"
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: camel-test
|
||||
|
|
|
@ -30,6 +30,6 @@ spec:
|
|||
simple: "${body.text}"
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: camel-test
|
||||
|
|
|
@ -23,6 +23,6 @@ spec:
|
|||
constant: Hello world!
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: messaging.knative.dev/v1alpha1
|
||||
apiVersion: messaging.knative.dev/v1beta1
|
||||
kind: InMemoryChannel
|
||||
name: camel-test
|
||||
|
|
|
@ -181,7 +181,7 @@ cd knative-docs/docs/eventing/samples/helloworld/helloworld-go
|
|||
targetPort: 8080
|
||||
---
|
||||
# Knative Eventing Trigger to trigger the helloworld-go service
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: helloworld-go
|
||||
|
@ -379,7 +379,7 @@ mesh via the Broker and can be delivered to other services using a Trigger
|
|||
|
||||
```shell
|
||||
kubectl --namespace knative-samples apply --filename - << END
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: event-display
|
||||
|
|
|
@ -13,6 +13,6 @@ spec:
|
|||
googleCloudProject: PROJECT_ID
|
||||
topic: TOPIC_NAME
|
||||
sink:
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: iot-demo
|
||||
|
|
|
@ -11,6 +11,6 @@ spec:
|
|||
kind: Event
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: testevents-trigger
|
||||
|
|
|
@ -100,7 +100,7 @@ all the YAML files deployed in this sample to point at that namespace.
|
|||
kind: Event
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
```
|
||||
|
@ -123,7 +123,7 @@ simple Knative Service that dumps incoming messages to its log and creates a
|
|||
1. Create a file named `trigger.yaml` and copy the code block below into it.
|
||||
|
||||
```yaml
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: testevents-trigger
|
||||
|
|
|
@ -11,6 +11,6 @@ spec:
|
|||
kind: Event
|
||||
sink:
|
||||
ref:
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Broker
|
||||
name: default
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: testevents-trigger
|
||||
|
|
|
@ -144,7 +144,7 @@ spec:
|
|||
reply:
|
||||
ref:
|
||||
kind: Sequence
|
||||
apiVersion: flows.knative.dev/v1alpha1
|
||||
apiVersion: flows.knative.dev/v1beta1
|
||||
name: second-sequence
|
||||
```
|
||||
|
||||
|
|
|
@ -196,7 +196,7 @@ spec:
|
|||
containers:
|
||||
- image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/appender
|
||||
---
|
||||
apiVersion: eventing.knative.dev/v1alpha1
|
||||
apiVersion: eventing.knative.dev/v1beta1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: display-trigger
|
||||
|
|
Loading…
Reference in New Issue