mirror of https://github.com/knative/docs.git
Fix many links in the Eventing folder (#4170)
* Fixed first half of links * Final markdown link fixes * Fix link to install doc
This commit is contained in:
RichardJJG
GitHub
parent
9aa9f556ba
commit
c3ae7f9dcd
|
|
@ -6,7 +6,7 @@ visualize and trace your requests.
|
|||
|
||||
## Before you begin
|
||||
|
||||
You must have a Knative cluster running with the Eventing component installed. [Learn more](../../admin/install/)
|
||||
You must have a Knative cluster running with the Eventing component installed. [Learn more](../admin/install/README.md).
|
||||
|
||||
## Configuring tracing
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,9 @@
|
|||
|
||||
Brokers are Kubernetes [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) that define an event mesh for collecting a pool of [CloudEvents](https://cloudevents.io/). Brokers provide a discoverable endpoint, `status.address`, for event ingress, and triggers for event delivery. Event producers can send events to a broker by POSTing the event to the `status.address.url` of the broker.
|
||||
|
||||
Event delivery mechanics are an implementation detail that depend on the configured [broker class](configmaps#broker-class-options). Using brokers and triggers abstracts the details of event routing from the event producer and event consumer.
|
||||
Event delivery mechanics are an implementation detail that depend on the configured
|
||||
[broker class](../../admin/eventing/broker-configuration.md#broker-class-options).
|
||||
Using brokers and triggers abstracts the details of event routing from the event producer and event consumer.
|
||||
|
||||
<img src="images/broker-workflow.svg" width="70%">
|
||||
|
||||
|
|
@ -24,7 +26,8 @@ The following broker types are available for use with Knative Eventing.
|
|||
|
||||
Knative Eventing provides a multi-tenant (MT) channel-based broker implementation that uses channels for event routing.
|
||||
|
||||
Before you can use the MT channel-based broker, you must install a [channel implementation](../channels/channel-types-defaults).
|
||||
Before you can use the MT channel-based broker, you must install a
|
||||
[channel implementation](../channels/channel-types-defaults.md).
|
||||
|
||||
### Alternative broker implementations
|
||||
|
||||
|
|
@ -38,7 +41,7 @@ The GCP broker is optimized for running in GCP. For more details, refer to the [
|
|||
|
||||
#### Apache Kafka broker
|
||||
|
||||
For information about the Apache Kafka broker, see [link](kafka-broker).
|
||||
For more information, see [Apache Kafka Broker](kafka-broker/README.md).
|
||||
|
||||
#### RabbitMQ broker
|
||||
|
||||
|
|
@ -46,6 +49,6 @@ The RabbitMQ Broker uses [RabbitMQ](https://www.rabbitmq.com/) for its underlyin
|
|||
|
||||
## Next steps
|
||||
|
||||
- Create a [MT channel-based broker](create-mtbroker).
|
||||
- Configure [default broker ConfigMap settings](configmaps/).
|
||||
- Create an [MT channel-based broker](create-mtbroker.md).
|
||||
- Configure [default broker ConfigMap settings](../../admin/eventing/broker-configuration.md).
|
||||
- View the [broker specifications](https://github.com/knative/specs/blob/main/specs/eventing/broker.md).
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ You can create a broker by using the `kn` CLI or by applying YAML files using `k
|
|||
|
||||
=== "kubectl"
|
||||
|
||||
The YAML in the following example creates a broker named `default` in the current namespace. For more information about configuring broker options using YAML, see the full [broker configuration example](../example-mtbroker).
|
||||
The YAML in the following example creates a broker named `default` in the current namespace. For more information about configuring broker options using YAML, see the full [broker configuration example](example-mtbroker.md).
|
||||
|
||||
1. Create a broker in the current namespace by creating a YAML file using the
|
||||
following template:
|
||||
|
|
|
|||
|
|
@ -31,6 +31,6 @@ metadata:
|
|||
|
||||
- You can specify any valid `name` for your broker. Using `default` will create a broker named `default`.
|
||||
- The `namespace` must be an existing namespace in your cluster. Using `default` will create the broker in the current namespace.
|
||||
- You can set the `eventing.knative.dev/broker.class` annotation to change the class of the broker. The default broker class is `MTChannelBasedBroker`, but Knative also supports use of the `Kafka` broker class. For more information about Kafka brokers, see the [Apache Kafka Broker](../kafka-broker) documentation.
|
||||
- `spec.config` is used to specify the default backing channel configuration for MT channel-based broker implementations. For more information on configuring the default channel type, see the documentation on [ConfigMaps](../configmaps).
|
||||
- `spec.delivery` is used to configure event delivery options. Event delivery options specify what happens to an event that fails to be delivered to an event sink. For more information, see the documentation on [broker event delivery](../broker-event-delivery).
|
||||
- You can set the `eventing.knative.dev/broker.class` annotation to change the class of the broker. The default broker class is `MTChannelBasedBroker`, but Knative also supports use of the `Kafka` broker class. For more information about Kafka brokers, see the [Apache Kafka Broker](kafka-broker/README.md) documentation.
|
||||
- `spec.config` is used to specify the default backing channel configuration for MT channel-based broker implementations. For more information on configuring the default channel type, see the documentation on [Configure Broker defaults](../../admin/eventing/broker-configuration.md).
|
||||
- `spec.delivery` is used to configure event delivery options. Event delivery options specify what happens to an event that fails to be delivered to an event sink. For more information, see the documentation on [Event delivery](../../developer/eventing/event-delivery.md).
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ Notable features are:
|
|||
|
||||
## Prerequisites
|
||||
|
||||
1. [Installing Eventing using YAML files](../../../admin/install/install-eventing-with-yaml).
|
||||
1. [Installing Eventing using YAML files](../../../admin/install/eventing/install-eventing-with-yaml.md).
|
||||
2. An Apache Kafka cluster (if you're just getting started you can follow [Strimzi Quickstart page](https://strimzi.io/quickstarts/)).
|
||||
|
||||
## Installation
|
||||
|
|
|
|||
|
|
@ -8,6 +8,6 @@ A channel provides an event delivery mechanism that can fan-out received events,
|
|||
|
||||
## Next steps
|
||||
|
||||
- Learn about [default available channel types](channel-types-defaults)
|
||||
- Create a [channel](create-default-channel)
|
||||
- Create a [subscription](subscriptions)
|
||||
- Learn about [default available channel types](channel-types-defaults.md)
|
||||
- Create a [channel](create-default-channel.md)
|
||||
- Create a [subscription](subscriptions.md)
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Cluster administrators can modify the default Channel implementation settings by
|
|||
|
||||
|
||||
For more information about modifying ConfigMaps, see
|
||||
[Configuring the Eventing Operator custom resource](/admin/install/operator/configuring-eventing-cr/#setting-a-default-channel).
|
||||
[Configuring the Eventing Operator custom resource](../../admin/install/operator/configuring-eventing-cr.md#setting-a-default-channel).
|
||||
|
||||
Default Channels can be configured for the cluster, a namespace on the cluster, or both.
|
||||
|
||||
|
|
@ -62,4 +62,4 @@ data:
|
|||
## Next steps
|
||||
|
||||
|
||||
- Create an [InMemoryChannel](../create-default-channel)
|
||||
- Create an [InMemoryChannel](create-default-channel.md)
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ using the following template:
|
|||
Where `<filename>` is the name of the file you created in the previous step.
|
||||
|
||||
If you create this object in the `default` namespace, according to the default ConfigMap
|
||||
example in [Channel types and defaults](/eventing/channels/channel-types-defaults), it is an
|
||||
example in [Channel types and defaults](channel-types-defaults.md), it is an
|
||||
InMemoryChannel Channel implementation.
|
||||
|
||||
<!-- TODO: Add tabs for kn etc-->
|
||||
|
|
@ -52,7 +52,7 @@ Where:
|
|||
* `<example-channel>` is the name of the Channel you want to create.
|
||||
* `<namespace>` is the name of your target namespace.
|
||||
* `<channel-template-kind>` is the kind of Channel, such as InMemoryChannel or KafkaChannel,
|
||||
based on the default ConfigMap. See an example in [Channel types and defaults](/eventing/channels/channel-types-defaults).
|
||||
based on the default ConfigMap. See an example in [Channel types and defaults](channel-types-defaults.md).
|
||||
|
||||
!!! note
|
||||
The `spec.channelTemplate` property cannot be changed after creation, because it is
|
||||
|
|
|
|||
|
|
@ -144,4 +144,4 @@ You can delete a Subscription by using the `kn` or `kubectl` CLI tools.
|
|||
|
||||
## Next steps
|
||||
|
||||
- [Creating a Channel using cluster or namespace defaults](/eventing/channels/create-default-channel)
|
||||
- [Creating a Channel using cluster or namespace defaults](create-default-channel.md)
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ setup.
|
|||
## Audience
|
||||
|
||||
This document is intended for people that are familiar with the object model of
|
||||
[Knative Eventing](../). You don't need to be an expert, but do need to
|
||||
[Knative Eventing](../README.md). You don't need to be an expert, but do need to
|
||||
know roughly how things fit together.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Setup [Knative Eventing and an Eventing-contrib resource](../).
|
||||
1. Setup [Knative Eventing and an Eventing-contrib resource](../README.md).
|
||||
|
||||
## Example
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ This should return a single Pod, which if you inspect is the one generated by
|
|||
##### `chan`
|
||||
|
||||
`chan` uses the
|
||||
[`in-memory-channel`]( https://github.com/knative/eventing/tree/{{ branch }}/config/channels/in-memory-channel).
|
||||
[`in-memory-channel`](https://github.com/knative/eventing/tree/{{ branch }}/config/channels/in-memory-channel).
|
||||
This is a very basic channel and has few
|
||||
failure modes that will be exhibited in `chan`'s `status`.
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ kubectl --namespace knative-debug get channel.messaging.knative.dev chan --outpu
|
|||
```
|
||||
|
||||
If `status` is completely missing, it implies that something is wrong with the
|
||||
`in-memory-channel` controller. See [Channel Controller](./#channel-controller).
|
||||
`in-memory-channel` controller. See [Channel Controller](#channel-controller).
|
||||
|
||||
Next verify that `chan` is addressable:
|
||||
|
||||
|
|
@ -180,7 +180,7 @@ something went wrong during `chan` reconciliation. See
|
|||
|
||||
##### `src`
|
||||
|
||||
`src` is a [`ApiServerSource`](../sources/apiserversource).
|
||||
`src` is a [`ApiServerSource`](../../developer/eventing/sources/apiserversource/README.md).
|
||||
|
||||
First we will verify that `src` is writing to `chan`.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ type information in the cluster data store.
|
|||
|
||||
## Before you begin
|
||||
|
||||
1. Read about the [broker](../broker/) and [trigger](../broker/triggers/) objects.
|
||||
1. Read about the [Broker](broker/README.md) and [Trigger](broker/triggers/README.md) objects.
|
||||
1. Be familiar with the
|
||||
[CloudEvents spec](https://github.com/cloudevents/spec/blob/master/spec.md),
|
||||
particularly the
|
||||
[Context Attributes](https://github.com/cloudevents/spec/blob/master/spec.md#context-attributes)
|
||||
section.
|
||||
1. Be familiar with [event sources](../sources).
|
||||
1. Be familiar with [event sources](../developer/eventing/sources/README.md).
|
||||
|
||||
## Discovering events with the registry
|
||||
|
||||
|
|
@ -262,7 +262,7 @@ the next topic: How do we actually populate the registry in the first place?
|
|||
|
||||
If you are interested in more information regarding configuration options of a
|
||||
KafkaSource, please refer to the
|
||||
[KafKaSource sample](../samples/kafka/).
|
||||
[KafKaSource sample](samples/kafka/binding/README.md).
|
||||
|
||||
For this discussion, the relevant information from the YAML mentioned are the
|
||||
`sink` and the `topics`. We observe that the `sink` is of kind `Broker`. We
|
||||
|
|
@ -277,8 +277,8 @@ the next topic: How do we actually populate the registry in the first place?
|
|||
|
||||
## Next steps
|
||||
|
||||
1. [Installing Knative](../../admin/install/).
|
||||
1. [Installing Knative](../admin/install/README.md)
|
||||
|
||||
1. [Knative code samples](../samples/) is a useful resource to better understand
|
||||
1. [Knative code samples](samples/README.md) is a useful resource to better understand
|
||||
some of the Event Sources (remember to point them to a Broker if you want
|
||||
automatic registration of EventTypes in the registry).
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ For more details about the process, the feature phases, quality requirements and
|
|||
|
||||
## Before you begin
|
||||
|
||||
You must have a Knative cluster running with the Eventing component installed. [Learn more](../../admin/install/)
|
||||
You must have a Knative cluster running with the Eventing component installed. [Learn more](../admin/install/README.md)
|
||||
|
||||
## Experimental features configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -2,5 +2,5 @@
|
|||
|
||||
Knative Eventing provides a collection of [custom resource definitions (CRDs)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) that you can use to define event flows:
|
||||
|
||||
* [Sequence](sequence) is for defining an in-order list of functions.
|
||||
* [Parallel](parallel) is for defining a list of branches, each receiving the same CloudEvent.
|
||||
* [Sequence](sequence/README.md) is for defining an in-order list of functions.
|
||||
* [Parallel](parallel.md) is for defining a list of branches, each receiving the same CloudEvent.
|
||||
|
|
|
|||
|
|
@ -38,4 +38,4 @@ Parallel has three parts for the Status:
|
|||
|
||||
## Examples
|
||||
|
||||
Learn how to use Parallel by following the [examples](../../samples/parallel/)
|
||||
Learn how to use Parallel by following the [examples](../samples/parallel/README.md)
|
||||
|
|
|
|||
|
|
@ -39,18 +39,18 @@ Sequence has four parts for the Status:
|
|||
|
||||
## Examples
|
||||
|
||||
For each of the following examples, you use a [`PingSource`](../../sources/ping-source/) as the source of events.
|
||||
For each of the following examples, you use a [`PingSource`](../../../developer/eventing/sources/ping-source/README.md) as the source of events.
|
||||
|
||||
We also use a very simple [transformer](https://github.com/knative/eventing/blob/main/cmd/appender/main.go) which performs very trivial transformation of the incoming events to demonstrate they have passed through each stage.
|
||||
|
||||
### [Sequence with no reply (terminal last Step)](../sequence/sequence-terminal/)
|
||||
### [Sequence with no reply (terminal last Step)](../sequence/sequence-terminal/README.md)
|
||||
|
||||
For the first example, we'll use a 3 Step `Sequence` that is wired 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.
|
||||
|
||||
### [Sequence with reply (last Step produces output)](../sequence/sequence-reply-to-event-display/)
|
||||
### [Sequence with reply (last Step produces output)](../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 `PingSource`. Each of the steps simply tacks on "- Handled
|
||||
|
|
@ -60,7 +60,7 @@ 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](../sequence/sequence-reply-to-sequence/)
|
||||
### [Chaining Sequences together](../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 `PingSource`. Each of the steps simply tacks on "- Handled
|
||||
|
|
@ -71,7 +71,7 @@ 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 same message
|
||||
modifications as the first pipeline (with different steps however).
|
||||
|
||||
### [Using Sequence with Broker/Trigger model](../sequence/sequence-with-broker-trigger/)
|
||||
### [Using Sequence with Broker/Trigger model](../sequence/sequence-with-broker-trigger/README.md)
|
||||
|
||||
You can also create a Trigger which targets `Sequence`. This time we'll wire
|
||||
`PingSource` to send events to a `Broker` and then we'll have the `Sequence`
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Sequence wired to event-display
|
||||
|
||||
We are going to create the following logical configuration. We create a
|
||||
PingSource, feeding events to a [`Sequence`](../), then
|
||||
PingSource, feeding events to a [`Sequence`](../README.md), then
|
||||
taking the output of that `Sequence` and displaying the resulting output.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Sequence wired to another Sequence
|
||||
|
||||
We are going to create the following logical configuration. We create a
|
||||
PingSource, feeding events to a [`Sequence`](../), then
|
||||
PingSource, feeding events to a [`Sequence`](../README.md), then
|
||||
taking the output of that `Sequence` and sending it to a second `Sequence` and
|
||||
finally displaying the resulting output.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Sequence terminal
|
||||
|
||||
We are going to create the following logical configuration. We create a
|
||||
PingSource, feeding events to a [`Sequence`](../).
|
||||
PingSource, feeding events to a [`Sequence`](../README.md).
|
||||
Sequence can then do either external work, or out of band create additional
|
||||
events.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
We are going to create the following logical configuration. We create a
|
||||
PingSource, feeding events into the Broker, then we create a `Filter` that wires
|
||||
those events into a [`Sequence`](../) consisting of 3
|
||||
those events into a [`Sequence`](../README.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.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ kubectl create namespace event-example
|
|||
|
||||
## Adding a broker to the namespace
|
||||
|
||||
The [broker](../broker) allows you to route events to different event sinks or consumers.
|
||||
The [broker](broker/README.md) allows you to route events to different event sinks or consumers.
|
||||
|
||||
1. Add a broker named `default` to your namespace by creating a YAML file using
|
||||
the following template:
|
||||
|
|
@ -55,7 +55,7 @@ the following template:
|
|||
```
|
||||
|
||||
If `READY` is `False`, wait a few moments and then run the command again.
|
||||
If you continue to receive the `False` status, see the [Debugging Guide](../debugging/) to troubleshoot the issue.
|
||||
If you continue to receive the `False` status, see the [Debugging Guide](debugging/README.md) to troubleshoot the issue.
|
||||
|
||||
## Creating event consumers
|
||||
|
||||
|
|
@ -159,11 +159,11 @@ into a file:
|
|||
goodbye-display 1/1 1 1 16s
|
||||
```
|
||||
The number of replicas in the **READY** column should match the number of replicas in the **AVAILABLE** column.
|
||||
If the numbers do not match, see the [Debugging Guide](../debugging/) to troubleshoot the issue.
|
||||
If the numbers do not match, see the [Debugging Guide](debugging/README.md) to troubleshoot the issue.
|
||||
|
||||
## Creating triggers
|
||||
|
||||
A [trigger](../broker/triggers) defines the events that each event consumer receives.
|
||||
A [trigger](broker/triggers/README.md) defines the events that each event consumer receives.
|
||||
Brokers use triggers to forward events to the correct consumers.
|
||||
Each trigger can specify a filter that enables selection of relevant events based on the Cloud Event context attributes.
|
||||
|
||||
|
|
@ -237,7 +237,7 @@ Each trigger can specify a filter that enables selection of relevant events base
|
|||
|
||||
The `SUBSCRIBER_URI` has a value similar to `triggerName.namespaceName.svc.cluster.local`.
|
||||
The exact value depends on the broker implementation.
|
||||
If this value looks incorrect, see the [Debugging Guide](../debugging/) to troubleshoot the issue.
|
||||
If this value looks incorrect, see the [Debugging Guide](debugging/README.md) to troubleshoot the issue.
|
||||
|
||||
## Creating a pod as an event producer
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ creating your own event source as a ContainerSource.
|
|||
|
||||
### Prerequisites
|
||||
|
||||
1. Setup [Knative Serving](../../../serving).
|
||||
1. Setup [Knative Eventing and Sources](../../../eventing).
|
||||
1. Set up [Knative Serving](../../../serving/README.md).
|
||||
1. Set up [Knative Eventing and Sources](../../../eventing/README.md).
|
||||
|
||||
### Prepare the heartbeats image
|
||||
|
||||
|
|
@ -169,5 +169,4 @@ event source is a sample for your reference.
|
|||
|
||||
When the container image is ready, a YAML file will be used to create a concrete
|
||||
`ContainerSource`. Use [heartbeats-source.yaml](heartbeats-source.yaml) as a
|
||||
sample for reference. [Learn more about the ContainerSource
|
||||
specification](../../../eventing#containersource).
|
||||
sample for reference.
|
||||
|
|
|
|||
|
|
@ -5,12 +5,10 @@ by a Knative Service.
|
|||
|
||||
## Before you begin
|
||||
|
||||
1. Set up [Knative Serving](../../../serving).
|
||||
1. Ensure Knative Serving is [configured with a domain
|
||||
name](../../../serving/using-a-custom-domain.md)
|
||||
that allows GitHub to call into the cluster.
|
||||
1. Set up [Knative Serving](../../../serving/README.md).
|
||||
1. Ensure Knative Serving is [configured with a domain name](../../../serving/using-a-custom-domain.md) that allows GitHub to call into the cluster.
|
||||
1. You must ensure that your Knative cluster uses a static IP address refer to your provider's documentation.
|
||||
1. Set up [Knative Eventing](../../../eventing) with the GitHub source.
|
||||
1. Set up [Knative Eventing](../../../eventing/README.md) with the GitHub source.
|
||||
|
||||
### Create a Knative Service
|
||||
|
||||
|
|
|
|||
|
|
@ -10,13 +10,13 @@ Knative Service.
|
|||
You will need:
|
||||
|
||||
1. An internet-accessible Kubernetes cluster with Knative Serving installed.
|
||||
Follow the [installation instructions](../../../install/) if you
|
||||
Follow the [installation instructions](../../../admin/install/README.md) if you
|
||||
need to create one.
|
||||
1. Ensure Knative Serving is
|
||||
[configured with a domain name](../../../serving/using-a-custom-domain.md)
|
||||
1. You must ensure that your Knative cluster uses a static IP address refer to your provider's documentation.
|
||||
that allows GitLab to call into the cluster.
|
||||
1. Install [Knative Eventing](../../../eventing).
|
||||
1. Install [Knative Eventing](../../../eventing/README.md).
|
||||
|
||||
### Install GitLab Event Source
|
||||
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@ We will deploy the app as a
|
|||
[Kubernetes Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/)
|
||||
along with a
|
||||
[Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/).
|
||||
However, you can also deploy the app as a [Knative Serving Service](../../../serving/)
|
||||
However, you can also deploy the app as a [Knative Serving Service](../../../serving/README.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A Kubernetes cluster with [Knative Eventing](../../getting-started.md#installing-knative-eventing)
|
||||
installed.
|
||||
- If you decide to deploy the app as a Knative Serving Service then you will have to install
|
||||
[Knative Serving](../../../install/).
|
||||
[Knative Serving](../../../admin/install/README.md).
|
||||
- [Docker](https://www.docker.com) installed and running on your local machine,
|
||||
and a Docker Hub account configured (we'll use it for a container registry).
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ We will deploy the app as a
|
|||
along with a
|
||||
[Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/).
|
||||
However, you can also deploy the app as a
|
||||
[Knative Serving Service](../../../../serving/).
|
||||
[Knative Serving Service](../../../../serving/README.md).
|
||||
|
||||
Do the following steps to create the sample code and then deploy the app to your
|
||||
cluster. You can also download a working copy of the sample, by running the
|
||||
|
|
@ -24,7 +24,7 @@ cd knative-docs/docs/eventing/samples/helloworld/helloworld-go
|
|||
|
||||
## Before you begin
|
||||
|
||||
- A Kubernetes cluster with [Knative Eventing](../../../../admin/install) installed.
|
||||
- A Kubernetes cluster with [Knative Eventing](../../../../admin/install/README.md) installed.
|
||||
- [Docker](https://www.docker.com) installed and running on your local machine,
|
||||
and a Docker Hub account configured (we'll use it for a container registry).
|
||||
|
||||
|
|
@ -252,7 +252,7 @@ folder) you're ready to build and deploy the sample app.
|
|||
**Note:** you can also use injection based on labels with the
|
||||
Eventing sugar controller.
|
||||
For how to install the Eventing sugar controller, see
|
||||
[Install optional Eventing extensions](../../../../admin/install/install-extensions#install-optional-eventing-extensions).
|
||||
[Install optional Eventing extensions](../../../../admin/install/eventing/install-eventing-with-yaml.md#install-optional-eventing-extensions).
|
||||
|
||||
1. It deployed the helloworld-go app as a K8s Deployment and created a K8s
|
||||
service names helloworld-go. Verify using the following command.
|
||||
|
|
@ -277,7 +277,7 @@ application and trigger are ready, let's send a CloudEvent.
|
|||
|
||||
### Send CloudEvent to the Broker
|
||||
|
||||
We can send an http request directly to the [Broker](../../../broker/)
|
||||
We can send an http request directly to the [Broker](../../../broker/README.md)
|
||||
with correct CloudEvent headers set.
|
||||
|
||||
1. Deploy a curl pod and SSH into it
|
||||
|
|
@ -351,7 +351,7 @@ with another event.
|
|||
|
||||
```
|
||||
|
||||
Play around with the CloudEvent attributes in the curl command and the trigger specification to [understand how triggers work](../../../broker/triggers).
|
||||
Play around with the CloudEvent attributes in the curl command and the trigger specification to [understand how triggers work](../../../broker/triggers/README.md).
|
||||
|
||||
## Verify reply from helloworld-go app
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
A simple web app written in Python that you can use to test knative eventing. It shows how to consume a [CloudEvent](https://cloudevents.io/) in Knative eventing, and optionally how to respond back with another CloudEvent in the http response, by adding the Cloud Eventing headers outlined in the Cloud Events standard definition.
|
||||
|
||||
We will deploy the app as a [Kubernetes Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) along with a [Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/).
|
||||
However, you can also deploy the app as a [Knative Serving Service](../../../../serving/).
|
||||
However, you can also deploy the app as a [Knative Serving Service](../../../../serving/README.md).
|
||||
|
||||
Do the following steps to create the sample code and then deploy the app to your
|
||||
cluster. You can also download a working copy of the sample, by running the
|
||||
|
|
@ -17,7 +17,7 @@ cd knative-docs/docs/eventing/samples/helloworld/helloworld-python
|
|||
|
||||
## Before you begin
|
||||
|
||||
- A Kubernetes cluster with [Knative Eventing](../../../../admin/install) installed.
|
||||
- A Kubernetes cluster with [Knative Eventing](../../../../admin/install/README.md) installed.
|
||||
- [Docker](https://www.docker.com) installed and running on your local machine,
|
||||
and a Docker Hub account configured (we'll use it for a container registry).
|
||||
|
||||
|
|
@ -199,7 +199,7 @@ After you have deployed the application, and have verified that the namespace, s
|
|||
|
||||
### Send CloudEvent to the Broker
|
||||
|
||||
You can send an HTTP request directly to the Knative [broker](../../../broker) if the correct CloudEvent headers are set.
|
||||
You can send an HTTP request directly to the Knative [Broker](../../../broker/README.md) if the correct CloudEvent headers are set.
|
||||
|
||||
1. Deploy a curl pod and SSH into it:
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ The Helloworld-python app logs the context and the msg of the event you created
|
|||
{"msg":"Hi from Knative!"}
|
||||
|
||||
```
|
||||
Try the CloudEvent attributes in the curl command and the trigger specification to understand how [triggers](../../../broker/triggers) work.
|
||||
Try the CloudEvent attributes in the curl command and the trigger specification to understand how [Triggers](../../../broker/triggers/README.md) work.
|
||||
|
||||
## Verify reply from helloworld-python app
|
||||
The `helloworld-python` app replies with an event type `type= dev.knative.samples.hifromknative`, and source `source=knative/eventing/samples/hello-world`. The event enters the eventing mesh through the broker, and can be delivered to event sinks using a trigger
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ export IOTCORE_TOPIC_DEVICE="iot-demo-device-pubsub-topic"
|
|||
gcloud pubsub topics create $IOTCORE_TOPIC_DEVICE
|
||||
```
|
||||
|
||||
1. Setup [Knative Eventing](../../../eventing).
|
||||
1. Set up [Knative Eventing](../../../eventing/README.md).
|
||||
|
||||
#### GCP PubSub Source
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ via Kafka Source
|
|||
### Prerequisites
|
||||
|
||||
1. You must ensure that you meet the
|
||||
[prerequisites listed in the Apache Kafka overview](../).
|
||||
[prerequisites listed in the Apache Kafka overview](../../../broker/kafka-broker/README.md#prerequisites).
|
||||
2. This feature is available from Knative Eventing 0.15+
|
||||
|
||||
### Creating a `KafkaSource` source CRD
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ default Channel configuration for Knative Eventing.
|
|||
## Specifying Kafka as the default Channel implementation
|
||||
<!--TODO: Move to admin guide-->
|
||||
|
||||
1. To configure Kafka Channel as the [default channel configuration](../../../channels/channel-types-defaults), modify the `default-ch-webhook` ConfigMap so that it contains the following YAML:
|
||||
1. To configure Kafka Channel as the [default channel configuration](../../../channels/channel-types-defaults.md), modify the `default-ch-webhook` ConfigMap so that it contains the following YAML:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
|
|||
|
|
@ -12,12 +12,12 @@ All examples require:
|
|||
- Knative Serving
|
||||
|
||||
All examples are using the
|
||||
[default channel template](../../channels/create-default-channel).
|
||||
[default channel template](../../../eventing/channels/create-default-channel.md).
|
||||
|
||||
## Examples
|
||||
|
||||
Each of the following examples use
|
||||
[`PingSource`](../../sources/ping-source/) as the source of events.
|
||||
[`PingSource`](../../../developer/eventing/sources/ping-source/README.md) as the source of events.
|
||||
|
||||
We also use simple
|
||||
[functions](https://github.com/lionelvillard/knative-functions) to perform
|
||||
|
|
@ -25,5 +25,5 @@ trivial filtering, transformation and routing of the incoming events.
|
|||
|
||||
The examples are:
|
||||
|
||||
- [Parallel with multiple branches and global reply](multiple-branches/)
|
||||
- [Parallel with mutually exclusive cases](mutual-exclusivity/)
|
||||
- [Parallel with multiple branches and global reply](multiple-branches/README.md)
|
||||
- [Parallel with mutually exclusive cases](mutual-exclusivity/README.md)
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ The events produced by each branch are then sent to the `event-display` service.
|
|||
|
||||
## Prerequisites
|
||||
|
||||
Please refer to the sample overview for the [prerequisites](../).
|
||||
Please refer to the sample overview for the [prerequisites](../README.md).
|
||||
|
||||
### Create the Knative Services
|
||||
|
||||
|
|
|
|||
|
|
@ -4,16 +4,16 @@ In this example, we are going to see how we can create a Parallel with mutually
|
|||
exclusive branches.
|
||||
|
||||
This example is the same as the
|
||||
[multiple branches example](../multiple-branches/) except that we are
|
||||
[multiple branches example](../multiple-branches/README.md) except that we are
|
||||
now going to rely on the Knative
|
||||
[switch](https://github.com/lionelvillard/knative-functions#switch) function to
|
||||
provide a soft mutual exclusivity guarantee.
|
||||
provide a soft mutual exclusivity guarantee .
|
||||
|
||||
NOTE: this example must be deployed in the default namespace.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Please refer to the sample overview for the [prerequisites](../).
|
||||
Please refer to the sample overview for the [prerequisites](../README.md).
|
||||
|
||||
### Create the Knative Services
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue