From 64d108ea62a0e532facc498c591b03f2c827a92f Mon Sep 17 00:00:00 2001 From: "Matt Moore (via sockpuppet)" Date: Wed, 26 Jun 2019 14:01:25 +0000 Subject: [PATCH] Format markdown Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)` /assign @samodell --- .../sequence-reply-to-event-display/README.md | 96 +++++------ .../sequence-reply-to-sequence/README.md | 149 +++++++++--------- .../sequence/sequence-terminal/README.md | 101 ++++++------ .../sequence-with-broker-trigger/README.md | 89 ++++++----- docs/eventing/sequence.md | 95 +++++------ docs/install/Knative-custom-install.md | 4 +- docs/serving/configuring-the-autoscaler.md | 24 ++- docs/serving/knative-kubernetes-services.md | 23 ++- docs/serving/samples/gitwebhook-go/README.md | 86 +++++----- 9 files changed, 346 insertions(+), 321 deletions(-) diff --git a/docs/eventing/samples/sequence/sequence-reply-to-event-display/README.md b/docs/eventing/samples/sequence/sequence-reply-to-event-display/README.md index 22f34ef52b9..c0eb39809ca 100644 --- a/docs/eventing/samples/sequence/sequence-reply-to-event-display/README.md +++ b/docs/eventing/samples/sequence/sequence-reply-to-event-display/README.md @@ -8,29 +8,28 @@ type: "docs" ## 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. +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. +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. +Change `default` below to create the steps in the Namespace where you want +resources created. ```yaml apiVersion: serving.knative.dev/v1beta1 @@ -41,10 +40,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "0" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "0" --- apiVersion: serving.knative.dev/v1beta1 @@ -55,10 +54,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "1" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "1" --- apiVersion: serving.knative.dev/v1beta1 kind: Service @@ -68,13 +67,13 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "2" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "2" --- -``` +``` ```shell kubectl -n default create -f ./steps.yaml @@ -82,7 +81,8 @@ 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 +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 @@ -95,31 +95,31 @@ spec: 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 + - 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. +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 @@ -131,11 +131,11 @@ spec: template: spec: containers: - - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display + - 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. +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 @@ -143,8 +143,8 @@ 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. +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 @@ -166,7 +166,8 @@ 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. +You can now see the final output by inspecting the logs of the event-display +pods. ```shell kubectl -n default get pods @@ -174,7 +175,6 @@ 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 @@ -193,5 +193,5 @@ Data, } ``` -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. +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. diff --git a/docs/eventing/samples/sequence/sequence-reply-to-sequence/README.md b/docs/eventing/samples/sequence/sequence-reply-to-sequence/README.md index c8df7864239..c95fd89052a 100644 --- a/docs/eventing/samples/sequence/sequence-reply-to-sequence/README.md +++ b/docs/eventing/samples/sequence/sequence-reply-to-sequence/README.md @@ -8,29 +8,29 @@ type: "docs" ## 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. +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. +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. +Change `default` below to create the steps in the Namespace where you want +resources created. ```yaml apiVersion: serving.knative.dev/v1beta1 @@ -41,10 +41,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "0" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "0" --- apiVersion: serving.knative.dev/v1beta1 @@ -55,10 +55,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "1" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "1" --- apiVersion: serving.knative.dev/v1beta1 kind: Service @@ -68,10 +68,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "2" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "2" --- apiVersion: serving.knative.dev/v1beta1 kind: Service @@ -81,10 +81,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "3" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "3" --- apiVersion: serving.knative.dev/v1beta1 @@ -95,10 +95,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "4" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "4" --- apiVersion: serving.knative.dev/v1beta1 kind: Service @@ -108,13 +108,13 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "5" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "5" --- -``` +``` ```shell kubectl -n default create -f ./steps.yaml @@ -122,8 +122,9 @@ 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. +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 @@ -135,36 +136,36 @@ spec: 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 + - 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 +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. +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 @@ -176,25 +177,24 @@ spec: 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 + - 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 @@ -206,11 +206,11 @@ spec: template: spec: containerers: - - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display + - 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. +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 @@ -218,8 +218,8 @@ 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. +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 @@ -241,7 +241,8 @@ 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. +You can now see the final output by inspecting the logs of the event-display +pods. ```shell kubectl -n default get pods @@ -267,5 +268,5 @@ Data, } ``` -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. +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. diff --git a/docs/eventing/samples/sequence/sequence-terminal/README.md b/docs/eventing/samples/sequence/sequence-terminal/README.md index 480ba84f356..f0e811a20f5 100644 --- a/docs/eventing/samples/sequence/sequence-terminal/README.md +++ b/docs/eventing/samples/sequence/sequence-terminal/README.md @@ -1,29 +1,27 @@ -title: "Sequence terminal" -weight: 20 -type: "docs" +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. +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. +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 @@ -39,10 +37,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "0" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "0" --- apiVersion: serving.knative.dev/v1beta1 @@ -53,10 +51,10 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "1" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "1" --- apiVersion: serving.knative.dev/v1beta1 kind: Service @@ -66,13 +64,13 @@ spec: template: spec: containers: - - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 - env: - - name: STEP - value: "2" + - image: us.gcr.io/probable-summer-223122/cmd-03315b715ae8f3e08e3a9378df706fbb@sha256:2656f39a7fcb6afd9fc79e7a4e215d14d651dc674f38020d1d18c6f04b220700 + env: + - name: STEP + value: "2" --- -``` +``` ```shell kubectl -n default create -f ./steps.yaml @@ -80,7 +78,8 @@ 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 +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 @@ -93,31 +92,31 @@ spec: 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 + - 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. +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. +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 @@ -134,7 +133,7 @@ spec: ``` Here, if you are using different type of Channel, you need to change the -spec.channelTemplate to point to your desired Channel. +spec.channelTemplate to point to your desired Channel. ```shell kubectl -n default create -f ./cron-source.yaml @@ -142,9 +141,9 @@ 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. +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 @@ -185,7 +184,6 @@ Got Transport Context: Transport Context, ---------------------------- ``` - Then we can look at the output of the second Step in the `Sequence`: ```shell @@ -218,8 +216,9 @@ Got Transport Context: Transport Context, ---------------------------- ``` -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 :) +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`: @@ -253,5 +252,5 @@ Got Transport Context: Transport Context, ---------------------------- ``` -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" +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" diff --git a/docs/eventing/samples/sequence/sequence-with-broker-trigger/README.md b/docs/eventing/samples/sequence/sequence-with-broker-trigger/README.md index b139c185de9..a7766b92709 100644 --- a/docs/eventing/samples/sequence/sequence-with-broker-trigger/README.md +++ b/docs/eventing/samples/sequence/sequence-with-broker-trigger/README.md @@ -8,35 +8,34 @@ type: "docs" ## 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. +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. +**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. +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` +Change `default` below to create the steps in the Namespace where you have +configured your `Broker` ```yaml apiVersion: serving.knative.dev/v1beta1 @@ -82,15 +81,15 @@ spec: --- ``` - ```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. +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` @@ -104,36 +103,35 @@ spec: 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 + - 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`. +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. +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 @@ -153,8 +151,8 @@ 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`. +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 @@ -178,8 +176,8 @@ spec: name: sequence ``` -Change `default` below to create the `Sequence` in the Namespace where you have configured your -`Broker`. +Change `default` below to create the `Sequence` in the Namespace where you have +configured your `Broker`. ```shell kubectl -n default create -f ./trigger.yaml @@ -188,8 +186,9 @@ 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) +**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 @@ -200,7 +199,7 @@ spec: template: spec: containers: - - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display + - image: gcr.io/knative-releases/github.com/knative/eventing-sources/cmd/event_display --- apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger @@ -216,12 +215,12 @@ spec: kind: Service name: sequence-display --- + ``` -Change `default` below to create the `Sequence` in the Namespace where you have configured your -`Broker`. +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 ``` - diff --git a/docs/eventing/sequence.md b/docs/eventing/sequence.md index 9a1c1d788be..0cb5dfaae44 100644 --- a/docs/eventing/sequence.md +++ b/docs/eventing/sequence.md @@ -4,9 +4,9 @@ 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. +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 @@ -14,72 +14,75 @@ Sequence creates `Channel`s and `Subscription`s under the hood. 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. +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. - +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. +[`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 +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 ", for example the first Step in the -`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message. +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 +", 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 ", for example the first Step in the -`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message. +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 ", 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. +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 ", for example the first Step in the -`Sequence` will take the incoming message and append "- Handled by 0" to the incoming message. +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 ", 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). +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. - - - - +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. diff --git a/docs/install/Knative-custom-install.md b/docs/install/Knative-custom-install.md index 7ca29a61231..275b82de916 100644 --- a/docs/install/Knative-custom-install.md +++ b/docs/install/Knative-custom-install.md @@ -103,7 +103,7 @@ files from the Knative repositories: | Knative Install Filename | Notes | Dependencies | | ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **knative/serving** | | | -| [`serving.yaml`][1.1]† | Installs the Serving component. | | +| [`serving.yaml`][1.1]† | Installs the Serving component. | | | [`monitoring.yaml`][1.2]† | Installs the [ELK stack][2], [Prometheus][2.1], [Grafana][2.2], and [Zipkin][2.3]**\*** | Serving component | | [`monitoring-logs-elasticsearch.yaml`][1.3] | Installs only the [ELK stack][2]**\*** | Serving component | | [`monitoring-metrics-prometheus.yaml`][1.4] | Installs only [Prometheus][2.1]**\*** | Serving component | @@ -112,7 +112,7 @@ files from the Knative repositories: | [`monitoring-tracing-zipkin.yaml`][1.7] | Installs only [Zipkin][2.3].**\*** | Serving component, ELK stack (monitoring-logs-elasticsearch.yaml) | | [`monitoring-tracing-zipkin-in-mem.yaml`][1.8] | Installs only [Zipkin in-memory][2.3]**\*** | Serving component | | **knative/build** | | | -| [`build.yaml`][3.1]† | Installs the Build component. | | +| [`build.yaml`][3.1]† | Installs the Build component. | | | **knative/eventing** | | | | [`release.yaml`][4.1]† | Installs the Eventing component. Includes [ContainerSource](../eventing#containersource), [CronJobSource][6.2], the in-memory channel provisioner. | | | [`eventing.yaml`][4.2] | Installs the Eventing component. Includes [ContainerSource](../eventing#containersource) and [CronJobSource][6.2]. Does not include the in-memory channel provisioner. | | diff --git a/docs/serving/configuring-the-autoscaler.md b/docs/serving/configuring-the-autoscaler.md index 11a94546d15..68f66bcdcb2 100644 --- a/docs/serving/configuring-the-autoscaler.md +++ b/docs/serving/configuring-the-autoscaler.md @@ -10,7 +10,9 @@ provides fast, request-based autoscaling capabilities out of the box. # Configuring Knative Pod Autoscaler -To modify the Knative Pod Autoscaler (KPA) configuration, you must modify a Kubernetes ConfigMap called `config-autoscaler` in the `knative-serving` namespace. +To modify the Knative Pod Autoscaler (KPA) configuration, you must modify a +Kubernetes ConfigMap called `config-autoscaler` in the `knative-serving` +namespace. You can view the default contents of this ConfigMap using the following command. @@ -126,8 +128,9 @@ If there is no `/target` annotation, the autoscaler is configured as if ## Configuring scale bounds (minScale and maxScale) -The `minScale` and `maxScale` annotations can be used to configure the minimum and maximum number of pods that can serve applications. -These annotations can be used to prevent cold starts or to help control computing costs. +The `minScale` and `maxScale` annotations can be used to configure the minimum +and maximum number of pods that can serve applications. These annotations can be +used to prevent cold starts or to help control computing costs. `minScale` and `maxScale` can be configured as follows in the revision template; @@ -139,19 +142,26 @@ spec: autoscaling.knative.dev/maxScale: "10" ``` -Using these annotations in the revision template will propagate this to `PodAutoscaler` objects. `PodAutoscaler` objects are mutable and can be further modified later without modifying anything else in the Knative Serving system. +Using these annotations in the revision template will propagate this to +`PodAutoscaler` objects. `PodAutoscaler` objects are mutable and can be further +modified later without modifying anything else in the Knative Serving system. ``` edit podautoscaler ``` -**NOTE:** These annotations apply for the full lifetime of a revision. Even when a revision is not referenced by any route, the minimal pod count specified by `minScale` will still be provided. Keep in mind that non-routeable revisions may be garbage collected, which enables Knative to reclaim the resources. +**NOTE:** These annotations apply for the full lifetime of a revision. Even when +a revision is not referenced by any route, the minimal pod count specified by +`minScale` will still be provided. Keep in mind that non-routeable revisions may +be garbage collected, which enables Knative to reclaim the resources. ### Default behavior -If the `minScale` annotation is not set, pods will scale to zero (or to 1 if `enable-scale-to-zero` is `false` per the ConfigMap mentioned above). +If the `minScale` annotation is not set, pods will scale to zero (or to 1 if +`enable-scale-to-zero` is `false` per the ConfigMap mentioned above). -If the `maxScale` annotation is not set, there will be no upper limit for the number of pods created. +If the `maxScale` annotation is not set, there will be no upper limit for the +number of pods created. ## Configuring CPU-based autoscaling diff --git a/docs/serving/knative-kubernetes-services.md b/docs/serving/knative-kubernetes-services.md index 4d4026abb05..14288e527e8 100644 --- a/docs/serving/knative-kubernetes-services.md +++ b/docs/serving/knative-kubernetes-services.md @@ -7,7 +7,9 @@ type: "docs" This document describes what is running when running knative serving. -After applying the serving yaml, this will install a few knative services and deployments on your kubernetes cluster. This document provides an overview of the deployments and the motivations for each one. +After applying the serving yaml, this will install a few knative services and +deployments on your kubernetes cluster. This document provides an overview of +the deployments and the motivations for each one. ```sh $ kubectl get services -n knative-serving @@ -34,21 +36,28 @@ webhook 1 1 1 1 1h ## Service: activator The responsibilities of the activator are: -* Receiving & buffering requests for inactive Revisions. -* Reporting metrics to the autoscaler. -* Retrying requests to a Revision after the autoscaler scales such Revision based on the reported metrics. + +- Receiving & buffering requests for inactive Revisions. +- Reporting metrics to the autoscaler. +- Retrying requests to a Revision after the autoscaler scales such Revision + based on the reported metrics. ## Service: autoscaler -The autoscaler receives request metrics and adjusts the number of pods required to handle the load of traffic. +The autoscaler receives request metrics and adjusts the number of pods required +to handle the load of traffic. ## Service: controller -The controller service reconciles all the public knative objects and autoscaling CRDs. When a user applies a knative service to the kubernetes api, this creates the config and route. It will convert config into revisions. It will convert Revision into Deployment and KPA. +The controller service reconciles all the public knative objects and autoscaling +CRDs. When a user applies a knative service to the kubernetes api, this creates +the config and route. It will convert config into revisions. It will convert +Revision into Deployment and KPA. ## Service: webhook -The webhook intercepts all kubernetes api calls, all crd insertions and updates. It does two things: +The webhook intercepts all kubernetes api calls, all crd insertions and updates. +It does two things: 1. Set default values 2. Rejects inconsitent and invalid objects. diff --git a/docs/serving/samples/gitwebhook-go/README.md b/docs/serving/samples/gitwebhook-go/README.md index 4f3624bd6fc..6adfb82040d 100644 --- a/docs/serving/samples/gitwebhook-go/README.md +++ b/docs/serving/samples/gitwebhook-go/README.md @@ -8,13 +8,12 @@ You must meet the following requirements to run this sample: - Own a public domain. For example, you can create a domain with [Google Domains](https://domains.google/). - A Kubernetes cluster running with the following: - - Knative Serving must be installed. For details about - setting up a Knative cluster, see the - [installation guides](../../../install/README.md). - - Your Knative cluster must be + - Knative Serving must be installed. For details about setting up a Knative + cluster, see the [installation guides](../../../install/README.md). + - Your Knative cluster must be [configured to use your custom domain](../../using-a-custom-domain.md). - You must ensure that your Knative cluster uses a static IP address: - - For Google Kubernetes Engine, see + - For Google Kubernetes Engine, see [assigning a static IP address](../../gke-assigning-static-ip-address.md). - For other cloud providers, refer to your provider's documentation. - An installed version of [Docker](https://www.docker.com). @@ -30,8 +29,9 @@ You must meet the following requirements to run this sample: cd knative-docs/serving/samples/gitwebhook-go ``` -1. Use Docker to build a container image for this service. Replace `{DOCKER_HUB_USERNAME}` - with your Docker Hub username in the following commands. +1. Use Docker to build a container image for this service. Replace + `{DOCKER_HUB_USERNAME}` with your Docker Hub username in the following + commands. ```shell export DOCKER_HUB_USERNAME=username @@ -44,13 +44,17 @@ You must meet the following requirements to run this sample: ``` 1. Create a secret that holds two values from GitHub: - - A [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) - that you will use to make API requests to GitHub. - - Ensure that you grant `read/write` permission in the repo for that personal access token. + + - A + [personal access token](https://help.github.com/articles/creating-a-personal-access-token-for-the-command-line/) + that you will use to make API requests to GitHub. + - Ensure that you grant `read/write` permission in the repo for that personal + access token. 1. Follow the GitHub instructions to - - A webhook secret that you will use to validate requests. - + + - A webhook secret that you will use to validate requests. + 1. Base64 encode the access token: ```shell @@ -60,7 +64,7 @@ You must meet the following requirements to run this sample: 1. Copy the encoded access token into `github-secret.yaml` next to `personalAccessToken:`. - + 1. Create a webhook secert value unique to this sample, base64 encode it, and copy it into `github-secret.yaml` next to `webhookSecret:`: @@ -88,19 +92,19 @@ You must meet the following requirements to run this sample: template: spec: containers: - - # Replace {DOCKER_HUB_USERNAME} with your actual docker hub username - image: docker.io/{DOCKER_HUB_USERNAME}/gitwebhook-go:latest - env: - - name: GITHUB_PERSONAL_TOKEN - valueFrom: - secretKeyRef: - name: githubsecret - key: personalAccessToken - - name: WEBHOOK_SECRET - valueFrom: - secretKeyRef: - name: githubsecret - key: webhookSecret + - # Replace {DOCKER_HUB_USERNAME} with your actual docker hub username + image: docker.io/{DOCKER_HUB_USERNAME}/gitwebhook-go:latest + env: + - name: GITHUB_PERSONAL_TOKEN + valueFrom: + secretKeyRef: + name: githubsecret + key: personalAccessToken + - name: WEBHOOK_SECRET + valueFrom: + secretKeyRef: + name: githubsecret + key: webhookSecret ``` 1. Use `kubectl` to apply the `service.yaml` file. @@ -108,14 +112,15 @@ You must meet the following requirements to run this sample: ```shell $ kubectl apply --filename service.yaml ``` - + Response: - + ```shell service "gitwebhook" created ``` -1. Create a webhook in your GitHub repo using the URL for your `gitwebhook` service: +1. Create a webhook in your GitHub repo using the URL for your `gitwebhook` + service: 1. Retrieve the hostname for this service, using the following command: @@ -123,37 +128,36 @@ You must meet the following requirements to run this sample: $ kubectl get ksvc gitwebhook \ --output=custom-columns=NAME:.metadata.name,DOMAIN:.status.domain ``` - + Example response: - + ```shell NAME DOMAIN gitwebhook gitwebhook.default.MYCUSTOMDOMAIN.com ``` - + where `MYCUSTOMDOMAIN` is the domain that you set as your [custom domain](../../using-a-custom-domain.md). 1. Go to the GitHub repository for which you have privileges to create a webhook. - + 1. Click **Settings** > **Webhooks** > **Add webhook** to open the Webhooks page. - + 1. Enter the **Payload URL** as `http://{DOMAIN}`, where `{DOMAIN}` is the - address from the `kubectl get ksvc gitwebhook` command. - For example: `http://gitwebhook.default.MYCUSTOMDOMAIN.com` + address from the `kubectl get ksvc gitwebhook` command. For example: + `http://gitwebhook.default.MYCUSTOMDOMAIN.com` 1. Set the **Content type** to `application/json`. - + 1. Enter your webhook secret in **Secret** using the original base value that you set in `webhookSecret` (not the base64 encoded value). For example: `mygithubwebhooksecret` - - 1. If you did not - [enabled TLS certificates](../../using-a-tls-cert.md), + + 1. If you did not [enabled TLS certificates](../../using-a-tls-cert.md), click **Disable** under **SSL Validation**. - + 1. Click **Add webhook** to create the webhook. ## Exploring