diff --git a/modules/apiserversource-kn-delete.adoc b/modules/apiserversource-kn-delete.adoc index 32f43fab4d9d..9337da86196c 100644 --- a/modules/apiserversource-kn-delete.adoc +++ b/modules/apiserversource-kn-delete.adoc @@ -3,40 +3,33 @@ // serverless/knative_eventing/serverless-kn-source.adoc [id="delete-apiserversource-kn_{context}"] -= Deleting the ApiServerSource using the Knative CLI (`kn`) += Deleting an API server source using the Knative CLI -This section describes the steps used to delete the ApiServerSource, trigger, service, service account, cluster role, and cluster binding using `kn` and `oc` commands. +This section describes the steps used to delete the `ApiServerSource` object, trigger, service, service account, cluster role, and cluster binding using the `kn` and `oc` commands. .Prerequisites * You must have the `kn` CLI installed. .Procedure - . Delete the trigger: + - [source,terminal] ---- $ kn trigger delete ---- - . Delete the service: + - [source,terminal] ---- $ kn service delete ---- - -. Delete the event source: +. Delete the API server source: + - [source,terminal] ---- $ kn source apiserver delete ---- - . Delete the service account, cluster role, and cluster binding: [source,terminal] diff --git a/modules/apiserversource-kn.adoc b/modules/apiserversource-kn.adoc index 193adf46e5e7..d8c043b6c6cc 100644 --- a/modules/apiserversource-kn.adoc +++ b/modules/apiserversource-kn.adoc @@ -3,23 +3,22 @@ // serverless/knative_eventing/serverless-kn-source.adoc [id="apiserversource-kn_context"] -= Using the ApiServerSource with the Knative CLI (`kn`) += Using the API server source with the Knative CLI -This section describes the steps required to create an ApiServerSource using `kn` commands. +This section describes the steps required to create an `ApiServerSource` object using `kn` commands. .Prerequisites -* You will need to have a Knative Serving and Eventing installation. -* You will need to have created the `default` broker in the same namespace that the ApiServerSource will be installed in. -* You will need to have the `kn` CLI installed. +* Knative Serving and Eventing are installed on your cluster. +* You have created the `default` broker in the same namespace that the API server source will be installed in. +* You have the `kn` CLI installed. .Procedure -. Create a service account, role, and role binding for the ApiServerSource. +. Create a service account, role, and role binding for the `ApiServerSource` object. + You can do this by creating a file named `authentication.yaml` and copying the following sample code into it: + - [source,yaml] ---- apiVersion: v1 @@ -60,65 +59,51 @@ subjects: namespace: default <1> ---- + -<1> Change this namespace to the namespace that you have selected for installing ApiServerSource. +<1> Change this namespace to the namespace that you have selected for installing the API server source. + [NOTE] ==== -If you want to re-use an existing service account with the appropriate permissions, you must modify the `authentication.yaml` for that service account. +If you want to reuse an existing service account with the appropriate permissions, you must modify the `authentication.yaml` file for that service account. ==== + Create the service account, role binding and cluster binding: + - [source,terminal] ---- $ oc apply -f authentication.yaml ---- - -. Create an ApiServerSource that uses a broker as an event sink: +. Create an `ApiServerSource` object that uses a broker as an event sink: + - [source,terminal] ---- $ kn source apiserver create --sink broker: --resource "event:v1" --service-account --mode Resource ---- - . Create a Knative service that dumps incoming messages to its log: + - [source,terminal] ---- $ kn service create --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest ---- - . Create a trigger to filter events from the `default` broker to the service: + - [source,terminal] ---- $ kn trigger create --sink svc: ---- - . Create events by launching a Pod in the default namespace: + - [source,terminal] ---- $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display ---- - . Check that the controller is mapped correctly by inspecting the output generated by the following command: + - [source,terminal] ---- $ kn source apiserver describe testevents ---- - + .Example output -+ - [source,terminal] ---- Name: testevents @@ -149,24 +134,18 @@ You can verify that the Kubernetes events were sent to Knative by looking at the . Get the pods: + - [source,terminal] ---- $ oc get pods ---- - . View the message dumper function logs for the pods: + - [source,terminal] ---- $ oc logs $(oc get pod -o name | grep event-display) -c user-container ---- - + .Example output -+ - [source,terminal] ---- ☁️ cloudevents.Event diff --git a/modules/apiserversource-yaml-delete.adoc b/modules/apiserversource-yaml-delete.adoc index 54ea5c01c862..f9bd74405052 100644 --- a/modules/apiserversource-yaml-delete.adoc +++ b/modules/apiserversource-yaml-delete.adoc @@ -3,39 +3,32 @@ // serverless/knative_eventing/serverless-kn-source.adoc [id="delete-apiserversource-yaml_{context}"] -= Deleting the ApiServerSource += Deleting the API server source -This section describes how to delete the ApiServerSource, trigger, service, service account, cluster role, and cluster binding by deleting their YAML files. +This section describes how to delete the `ApiServerSource` object, trigger, service, service account, cluster role, and cluster binding by deleting their YAML files. .Procedure . Delete the trigger: + - [source,terminal] ---- $ oc delete -f trigger.yaml ---- - . Delete the service: + - [source,terminal] ---- $ oc delete -f service.yaml ---- - -. Delete the event source: +. Delete the API server source: + - [source,terminal] ---- $ oc delete -f k8s-events.yaml ---- - . Delete the service account, cluster role, and cluster binding: + - [source,terminal] ---- $ oc delete -f authentication.yaml diff --git a/modules/apiserversource-yaml.adoc b/modules/apiserversource-yaml.adoc index dce4a38b0e04..3667997bde52 100644 --- a/modules/apiserversource-yaml.adoc +++ b/modules/apiserversource-yaml.adoc @@ -3,20 +3,19 @@ // serverless/knative_eventing/serverless-kn-source.adoc [id="apiserversource-yaml_context"] -= Using the ApiServerSource with the YAML method += Creating an API server source using YAML files -This guide describes the steps required to create an ApiServerSource using YAML files. +This guide describes the steps required to create an `ApiServerSource` object using YAML files. .Prerequisites -* You will need to have a Knative Serving and Eventing installation. -* You will need to have created the `default` broker in the same namespace as the one defined in the ApiServerSource YAML file. +* Knative Serving and Eventing are installed on your cluster. +* You have created the `default` broker in the same namespace as the one defined in the `ApiServerSource` object. .Procedure -. To create a service account, role, and role binding for the ApiServerSource, create a file named `authentication.yaml` and copy the following sample code into it: +. To create a service account, role, and role binding for the API server source, create a file named `authentication.yaml` and copy the following sample code into it: + - [source,yaml] ---- apiVersion: v1 @@ -56,9 +55,8 @@ subjects: name: events-sa namespace: default <1> ---- - + -<1> Change this namespace to the namespace that you have selected for installing ApiServerSource. +<1> Change this namespace to the namespace that you have selected for installing the API server source. + [NOTE] ==== @@ -67,15 +65,12 @@ If you want to re-use an existing service account with the appropriate permissio + After you have created the `authentication.yaml` file, apply it: + - [source,terminal] ---- $ oc apply -f authentication.yaml ---- - -. To create an ApiServerSource event source, create a file named `k8s-events.yaml` and copy the following sample code into it: +. To create an `ApiServerSource` object, create a file named `k8s-events.yaml` and copy the following sample code into it: + - [source,yaml] ---- apiVersion: sources.knative.dev/v1alpha1 @@ -94,21 +89,17 @@ spec: kind: Broker name: default ---- - + After you have created the `k8s-events.yaml` file, apply it: + - [source,terminal] ---- $ oc apply -f k8s-events.yaml ---- - -. To check that the ApiServerSource is set up correctly, create a Knative service that dumps incoming messages to its log. +. To check that the API server source is set up correctly, create a Knative service that dumps incoming messages to its log. + Copy the following sample YAML into a file named `service.yaml`: + - [source,yaml] ---- apiVersion: serving.knative.dev/v1 @@ -122,19 +113,15 @@ spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:v0.13.2 ---- - + After you have created the `service.yaml` file, apply it: + - [source,terminal] ---- $ oc apply -f service.yaml ---- - . To create a trigger from the `default` broker that filters events to the service created in the previous step, create a file named `trigger.yaml` and copy the following sample code into it: + - [source,yaml] ---- apiVersion: eventing.knative.dev/v1alpha1 @@ -149,36 +136,27 @@ spec: kind: Service name: event-display ---- - + After you have created the `trigger.yaml` file, apply it: + - [source,terminal] ---- $ oc apply -f trigger.yaml ---- - -. To create events, launch a Pod in the default namespace: +. To create events, launch a pod in the `default` namespace: + - [source,terminal] ---- $ oc create deployment hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display ---- - . To check that the controller is mapped correctly, enter the following command and inspect the output: + - [source,terminal] ---- $ oc get apiserversource.sources.knative.dev testevents -o yaml ---- - + .Example output -+ - [source,yaml] ---- apiVersion: sources.knative.dev/v1alpha1 @@ -218,24 +196,18 @@ To verify that the Kubernetes events were sent to Knative, you can look at the m . Get the pods: + - [source,terminal] ---- $ oc get pods ---- - . View the message dumper function logs for the pods: + - [source,terminal] ---- $ oc logs $(oc get pod -o name | grep event-display) -c user-container ---- - + .Example output -+ - [source,terminal] ---- ☁️ cloudevents.Event diff --git a/modules/creating-serverless-apps-kn.adoc b/modules/creating-serverless-apps-kn.adoc index bd40a4b813ec..e44581caf543 100644 --- a/modules/creating-serverless-apps-kn.adoc +++ b/modules/creating-serverless-apps-kn.adoc @@ -17,7 +17,7 @@ The following procedure describes how you can create a basic serverless applicat + [source,terminal] ---- -$ kn service create --image --env +$ kn service create --image --env ---- + .Example command diff --git a/modules/serverless-about-collecting-data.adoc b/modules/serverless-about-collecting-data.adoc index 519df04e3f88..8dce7e4a550f 100644 --- a/modules/serverless-about-collecting-data.adoc +++ b/modules/serverless-about-collecting-data.adoc @@ -7,7 +7,7 @@ You can use the `oc adm must-gather` CLI command to collect information about your cluster, including features and objects associated with {ServerlessProductName}. -To collect {ServerlessProductName} data with `must-gather`, you must specify the {ServerlessProductName} image: +To collect {ServerlessProductName} data with the `must-gather` tool, you must specify the {ServerlessProductName} image: [source,terminal] ---- diff --git a/modules/serverless-jaeger-config.adoc b/modules/serverless-jaeger-config.adoc index cef44bc04e2e..99df87cf906a 100644 --- a/modules/serverless-jaeger-config.adoc +++ b/modules/serverless-jaeger-config.adoc @@ -9,8 +9,8 @@ .Prerequisites * Cluster administrator permissions on an {product-title} cluster. -* A current installation of {ServerlessOperatorName} and Knative Serving. -* A current installation of the Jaeger Operator. +* You have installed the {ServerlessOperatorName} and Knative Serving. +* You have installed the Jaeger Operator. .Procedure @@ -24,7 +24,7 @@ metadata: name: jaeger namespace: default ---- -. Enable tracing for Knative Serving, by editing the KnativeServing custom resource definition (CRD) and adding a YAML configuration for tracing: +. Enable tracing for Knative Serving by editing the `KnativeServing` custom resource definition (CRD) and adding a YAML configuration for tracing: + [source,yaml] ---- @@ -50,7 +50,7 @@ spec: You can access the Jaeger web console to see tracing data, by using the `jaeger` route. -. Get the `jaeger` route's hostname: +. Get the hostname of the `jaeger` route: + [source,terminal] ---- diff --git a/modules/serverless-list-source-types.adoc b/modules/serverless-list-source-types.adoc index f7bc92e8d21f..df17621921ef 100644 --- a/modules/serverless-list-source-types.adoc +++ b/modules/serverless-list-source-types.adoc @@ -3,14 +3,18 @@ // * serverless-kn-source.adoc [id="serverless-list-source-types_{context}"] -= Listing available event source types using `kn` += Listing available event source types using the Knative CLI You can list the available event source types in the terminal by using the following command: + +[source,terminal] ---- $ kn source list-types ---- The default output for this command will look like: + +[source,terminal] ---- TYPE NAME DESCRIPTION ApiServerSource apiserversources.sources.knative.dev Watch and send Kubernetes API events to a sink @@ -20,6 +24,7 @@ SinkBinding sinkbindings.sources.knative.dev Binding for co It is also possible to list available event source types in YAML format: +[source,terminal] ---- $ kn source list-types -o yaml ---- diff --git a/modules/serverless-list-source.adoc b/modules/serverless-list-source.adoc index 7fe2ea679849..03187b1880a6 100644 --- a/modules/serverless-list-source.adoc +++ b/modules/serverless-list-source.adoc @@ -3,10 +3,9 @@ // * serverless-kn-source.adoc [id="serverless-list-source_{context}"] -= Listing available event sources using `kn` += Listing available event sources using the Knative CLI -* List available event sources by entering the following command: -+ +You can list the available event sources in the terminal by using the following command: [source,terminal] ---- @@ -14,7 +13,6 @@ $ kn source list ---- .Example output - [source,terminal] ---- NAME TYPE RESOURCE SINK READY @@ -23,20 +21,14 @@ b1 SinkBinding sinkbindings.sources.knative.dev svc:eshow3 Fal p1 PingSource pingsources.sources.knative.dev svc:eshow1 True ---- -== Listing event sources of a specific type only - You can list event sources of a specific type only, by using the `--type` flag. -* List available event sources of type `PingSource` by entering the following command: -+ - [source,terminal] ---- $ kn source list --type PingSource ---- .Example output - [source,terminal] ---- NAME TYPE RESOURCE SINK READY diff --git a/modules/serverless-metering-datasources.adoc b/modules/serverless-metering-datasources.adoc index f8b497710300..80778f3fd029 100644 --- a/modules/serverless-metering-datasources.adoc +++ b/modules/serverless-metering-datasources.adoc @@ -67,11 +67,11 @@ spec: .Procedure -* Apply the `ReportDataSources` resource as a `.yaml` file: +* Apply the `ReportDataSources` resource as a YAML file: + [source,terminal] ---- -$ oc apply -f .yaml +$ oc apply -f .yaml ---- + .Example command diff --git a/modules/serverless-metering-queries.adoc b/modules/serverless-metering-queries.adoc index afca1c8a9c74..a34080a74065 100644 --- a/modules/serverless-metering-queries.adoc +++ b/modules/serverless-metering-queries.adoc @@ -4,10 +4,7 @@ [id="queries-metering-serverless_{context}"] = Queries for Knative Serving metering -[NOTE] -==== The following query example resources reference the example data sources. -==== [id="knative-service-cpu-usage-query_{context}"] == Query for CPU usage in Knative Serving @@ -120,13 +117,13 @@ spec: ---- [id="applying-queries-knative_{context}"] -== Applying Queries for Knative Serving metering +== Applying queries for Knative Serving metering -* Apply the query as a `.yaml` file: +* Apply the query as a YAML file: + [source,terminal] ---- -$ oc apply -f .yaml +$ oc apply -f .yaml ---- + .Example command diff --git a/modules/serverless-metering-reports.adoc b/modules/serverless-metering-reports.adoc index 99b18a35d6b9..ae55ff0d5eac 100644 --- a/modules/serverless-metering-reports.adoc +++ b/modules/serverless-metering-reports.adoc @@ -28,11 +28,11 @@ runImmediately: true [id="reports-metering-serverless-run_{context}"] == Running a metering report -. Run the report by applying it as a `.yaml` file: +. Run the report by applying it as a YAML file: + [source,terminal] ---- -$ oc apply -f .yml +$ oc apply -f .yaml ---- . Check the report: + diff --git a/modules/serverless-pingsource-kn.adoc b/modules/serverless-pingsource-kn.adoc index 11109499d757..acd4ee652211 100644 --- a/modules/serverless-pingsource-kn.adoc +++ b/modules/serverless-pingsource-kn.adoc @@ -3,9 +3,9 @@ // * serverless/knative_eventing/serverless-pingsource.adoc [id="serverless-pingsource-kn_{context}"] -= Using a PingSource with the `kn` CLI += Creating a ping source using the Knative CLI -The following sections describe how to create, verify and remove a basic PingSource using the `kn` CLI. +The following sections describe how to create, verify and remove a basic `PingSource` object using the `kn` CLI. .Prerequisites @@ -14,19 +14,16 @@ The following sections describe how to create, verify and remove a basic PingSou .Procedure -. To verify that the PingSource is working, create a simple Knative +. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service's logs: + - [source,terminal] ---- $ kn service create event-display \ --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest ---- - -. For each set of ping events that you want to request, create a PingSource in the same namespace as the event consumer: +. For each set of ping events that you want to request, create a `PingSource` object in the same namespace as the event consumer: + - [source,terminal] ---- $ kn source ping create test-ping-source \ @@ -34,19 +31,14 @@ $ kn source ping create test-ping-source \ --data '{"message": "Hello world!"}' \ --sink svc:event-display ---- - . Check that the controller is mapped correctly by entering the following command and inspecting the output: + - [source,terminal] ---- $ kn source ping describe test-ping-source ---- - + .Example output -+ - [source,terminal] ---- Name: test-ping-source @@ -73,31 +65,25 @@ Conditions: .Verification steps -You can verify that the Kubernetes events were sent to the Knative event sink by looking at the sink pod's logs. +You can verify that the Kubernetes events were sent to the Knative event sink by looking at the logs of the sink pod. By default, Knative services terminate their pods if no traffic is received within a 60 second period. -The example shown in this guide creates a PingSource that sends a message every 2 minutes, so each message should be observed in a newly created pod. +The example shown in this guide creates a `PingSource` object that sends a message every 2 minutes, so each message should be observed in a newly created pod. . Watch for new pods created: + - [source,terminal] ---- $ watch oc get pods ---- - -. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod: +. Cancel watching the pods using `Ctrl+C`, then look at the logs of the created pod: + - [source,terminal] ---- $ oc logs $(oc get pod -o name | grep event-display) -c user-container ---- - + .Example output -+ - [source,terminal] ---- ☁️ cloudevents.Event @@ -116,19 +102,16 @@ Data, ---- [id="pingsource-remove-kn_{context}"] -== Remove the PingSource +== Remove the ping source -. Delete the PingSource: +. Delete the `PingSource` object: + - [source,terminal] ---- $ kn delete pingsources.sources.knative.dev test-ping-source ---- - . Delete the `event-display` service: + - [source,terminal] ---- $ kn delete service.serving.knative.dev event-display diff --git a/modules/serverless-pingsource-yaml.adoc b/modules/serverless-pingsource-yaml.adoc index e715094ba37e..eae24dcddf54 100644 --- a/modules/serverless-pingsource-yaml.adoc +++ b/modules/serverless-pingsource-yaml.adoc @@ -3,9 +3,9 @@ // * serverless/knative_eventing/serverless-pingsource.adoc [id="serverless-pingsource-yaml_{context}"] -= Using a PingSource with YAML += Creating a ping source using YAML files -The following sections describe how to create, verify and remove a basic PingSource using YAML files. +The following sections describe how to create, verify and remove a basic ping source using YAML files. .Prerequisites @@ -20,11 +20,10 @@ If you change the names of the YAML files from those used in the examples, you m .Procedure -. To verify that the PingSource is working, create a simple Knative +. To verify that the ping source is working, create a simple Knative service that dumps incoming messages to the service's logs. .. Copy the example YAML into a file named `service.yaml`: + - [source,yaml] ---- apiVersion: serving.knative.dev/v1 @@ -37,19 +36,16 @@ spec: containers: - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest ---- - -.. Create the service: +.. Apply the `service.yaml` file: + - [source,terminal] ---- $ oc apply --filename service.yaml ---- -. For each set of ping events that you want to request, create a PingSource in the same namespace as the event consumer. +. For each set of ping events that you want to request, create a `PingSource` object in the same namespace as the event consumer. .. Copy the example YAML into a file named `ping-source.yaml`: + - [source,yaml] ---- apiVersion: sources.knative.dev/v1alpha2 @@ -65,27 +61,20 @@ spec: kind: Service name: event-display ---- - -.. Create the PingSource: +.. Apply the `ping-source.yaml` file: + - [source,terminal] ---- $ oc apply --filename ping-source.yaml ---- - -. Check that the controller is mapped correctly by entering the following command: +. Check that the controller is mapped correctly by entering the following command and observing the output: + - [source,terminal] ---- $ oc get pingsource.sources.knative.dev test-ping-source -oyaml ---- - + .Example output -+ - [source,terminal] ---- apiVersion: sources.knative.dev/v1alpha2 @@ -114,31 +103,25 @@ spec: .Verification steps -You can verify that the Kubernetes events were sent to the Knative event sink by looking at the sink pod's logs. +You can verify that the Kubernetes events were sent to the Knative event sink by looking at the logs of the sink pod. By default, Knative services terminate their pods if no traffic is received within a 60 second period. -The example shown in this guide creates a PingSource that sends a message every 2 minutes, so each message should be observed in a newly created pod. +The example shown in this guide creates a `PingSource` object that sends a message every 2 minutes, so each message should be observed in a newly created pod. . Watch for new pods created: + - [source,terminal] ---- $ watch oc get pods ---- - -. Cancel watching the pods using Ctrl+C, then look at the logs of the created pod: +. Cancel watching the pods using `Ctrl+C`, then look at the logs of the created pod: + - [source,terminal] ---- $ oc logs $(oc get pod -o name | grep event-display) -c user-container ---- - + .Example output -+ - [source,terminal] ---- ☁️ cloudevents.Event @@ -161,15 +144,12 @@ Data, . Delete the service by entering the following command: + - [source,terminal] ---- $ oc delete --filename service.yaml ---- - -. Delete the PingSource by entering the following command: +. Delete the `PingSource` object by entering the following command: + - [source,terminal] ---- $ oc delete --filename ping-source.yaml diff --git a/modules/serverless-rn-1-7-0.adoc b/modules/serverless-rn-1-7-0.adoc index 9f6da5144fea..bb1374950e7b 100644 --- a/modules/serverless-rn-1-7-0.adoc +++ b/modules/serverless-rn-1-7-0.adoc @@ -28,12 +28,12 @@ If you have installed a previous version of {ServerlessProductName}, after the ` + You can disable HA for these components by completing the procedure in the _Configuring high availability components_ documentation. * {ServerlessProductName} now supports the `trustedCA` setting in {product-title}'s cluster-wide proxy, and is now fully compatible with {product-title}'s proxy settings. -* {ServerlessProductName} now supports HTTPS using the wildcard certificate that is registered for {product-title} routes. For more information on `http` and `https` on Knative Serving, see the documentation on _Verifying your serverless application deployment_. +* {ServerlessProductName} now supports HTTPS by using the wildcard certificate that is registered for {product-title} routes. For more information on HTTP and HTTPS on Knative Serving, see the documentation on _Verifying your serverless application deployment_. [id="fixed-issues-1-7-0_{context}"] == Fixed issues -* In previous versions, requesting `KnativeServing` CRs without specifying an API group, for example, the command `oc get knativeserving -n knative-serving`, occasionally caused errors. This issue is fixed in {ServerlessProductName} 1.7.0. +* In previous versions, requesting `KnativeServing` CRs without specifying an API group, for example, by using the command `oc get knativeserving -n knative-serving`, occasionally caused errors. This issue is fixed in {ServerlessProductName} 1.7.0. * In previous versions, the Knative Serving controller was not notified when a new service CA certificate was generated due to service CA certificate rotation. New revisions created after a service CA certificate rotation were failing with the error: + [source,terminal] @@ -49,4 +49,4 @@ The {ServerlessOperatorName} now restarts the Knative Serving controller wheneve * If you are using Knative Eventing on an Azure cluster, it is possible that the `imc-dispatcher` pod may not start. This is due to the pod's default `resources` settings. As a work-around, you can remove the `resources` settings. * If you have 1000 Knative services on a cluster, and then perform a reinstall or upgrade of Knative Serving, there is a delay when you create the first new service after the `KnativeServing` CR becomes Ready. + -`3scale-kourier-control` reconciles all previous Knative services before processing the creation of a new service, which causes the new service to spend approximately 800 seconds in an `IngressNotConfigured` or `Unknown` state before the state will update to `Ready`. +The `3scale-kourier-control` controller reconciles all previous Knative services before processing the creation of a new service, which causes the new service to spend approximately 800 seconds in an `IngressNotConfigured` or `Unknown` state before the state will update to `Ready`. diff --git a/modules/verifying-serverless-app-deployment.adoc b/modules/verifying-serverless-app-deployment.adoc index 93b1e0753965..338219ed72e3 100644 --- a/modules/verifying-serverless-app-deployment.adoc +++ b/modules/verifying-serverless-app-deployment.adoc @@ -9,7 +9,7 @@ To verify that your serverless application has been deployed successfully, you m [NOTE] ==== -{ServerlessProductName} supports the use of both HTTP and HTTPS URLs, however the output from `oc get ksvc ` always prints URLs using the `http://` format. +{ServerlessProductName} supports the use of both HTTP and HTTPS URLs, however the output from `oc get ksvc ` always prints URLs using the `http://` format. ==== .Procedure @@ -18,7 +18,7 @@ To verify that your serverless application has been deployed successfully, you m + [source,terminal] ---- -$ oc get ksvc +$ oc get ksvc ---- + .Example output diff --git a/serverless/architecture/serverless-event-architecture.adoc b/serverless/architecture/serverless-event-architecture.adoc index d6e48b10fad4..119df381ec78 100644 --- a/serverless/architecture/serverless-event-architecture.adoc +++ b/serverless/architecture/serverless-event-architecture.adoc @@ -20,14 +20,11 @@ You can propagate an event from an xref:../event_sources/knative-event-sources.a The channel and broker implementations manage delivery of events to event sinks, by using subscriptions and triggers. Events are buffered if the destination sink is unavailable. -// For more information about creating an Event delivery system, see -// Add link to getting started or tutorial landing page for eventing + Knative Eventing supports the following scenarios: Publish an event without creating a consumer:: You can send events to a Broker as an HTTP POST, and use a sink binding to decouple the destination configuration from your application that is producing events. Consume an event without creating a publisher:: You can use a trigger to consume events from a broker based on event attributes. Your application receives events as an HTTP POST. -// Use Channels and Subscriptions to define complex message-passing topologies:: For simple pipelines, the Sequence automates construction of Channels and Subscriptions between each stage. -// Knative also supports some additional patterns such as Parallel fanout of events, and routing response events from both Channels and Brokers [id="serverless-event-architecture-sinks"] == Event sinks diff --git a/serverless/event_sources/images b/serverless/event_sources/images new file mode 120000 index 000000000000..5e67573196d8 --- /dev/null +++ b/serverless/event_sources/images @@ -0,0 +1 @@ +../images \ No newline at end of file diff --git a/serverless/event_sources/knative-event-sources.adoc b/serverless/event_sources/knative-event-sources.adoc index 314ddf398277..95b875081a9c 100644 --- a/serverless/event_sources/knative-event-sources.adoc +++ b/serverless/event_sources/knative-event-sources.adoc @@ -10,7 +10,7 @@ An _event source_ is an object that links an event producer with an event _sink_ Currently, {ServerlessProductName} supports the following event source types: ApiServerSource:: Connects a sink to the Kubernetes API server. -PingSource:: Periodically sends ping Events with a constant payload. It can be used as a timer. +PingSource:: Periodically sends ping events with a constant payload. It can be used as a timer. xref:../../serverless/knative_eventing/serverless-sinkbinding.adoc#serverless-sinkbinding[Sink binding] is also supported, which allows you to connect core Kubernetes resources such as `Deployment`, `Job`, or `StatefulSet` with a sink. diff --git a/serverless/event_sources/modules b/serverless/event_sources/modules new file mode 120000 index 000000000000..464b823aca16 --- /dev/null +++ b/serverless/event_sources/modules @@ -0,0 +1 @@ +../modules \ No newline at end of file diff --git a/serverless/event_sources/serverless-apiserversource.adoc b/serverless/event_sources/serverless-apiserversource.adoc index 081be637736c..a50137237229 100644 --- a/serverless/event_sources/serverless-apiserversource.adoc +++ b/serverless/event_sources/serverless-apiserversource.adoc @@ -1,13 +1,13 @@ include::modules/serverless-document-attributes.adoc[] [id="serverless-apiserversource"] -= Using ApiServerSource += Using the API server source include::modules/common-attributes.adoc[] :context: serverless-apiserversource toc::[] -ApiServerSource is an event source that can be used to connect an event sink, such as a Knative service, to the Kubernetes API server. -ApiServerSource watches for Kubernetes events and forwards them to the Knative Eventing broker. +An API server source is an event source that can be used to connect an event sink, such as a Knative service, to the Kubernetes API server. +An API server source watches for Kubernetes events and forwards them to the Knative Eventing broker. [NOTE] ==== diff --git a/serverless/event_sources/serverless-kn-source.adoc b/serverless/event_sources/serverless-kn-source.adoc index ffa513308e7e..2775292a18c2 100644 --- a/serverless/event_sources/serverless-kn-source.adoc +++ b/serverless/event_sources/serverless-kn-source.adoc @@ -1,6 +1,6 @@ include::modules/serverless-document-attributes.adoc[] [id="serverless-kn-source"] -= Using the `kn` CLI to list event sources and event source types += Using the Knative CLI to list event sources and event source types include::modules/common-attributes.adoc[] :context: serverless-kn-source @@ -10,16 +10,12 @@ You can use the `kn` CLI to list and manage available event sources or event sou Currently, `kn` supports management of the following event source types: -ApiServerSource:: Connects a sink to the Kubernetes API server. -PingSource:: Periodically sends ping events with a constant payload. It can be used as a timer. - -// Additional sources can be added by the cluster administrator. For example, {ServerlessProductName} can be used with Kafka and Camel K event sources, which are installed using the Operator Hub in the {product-title} web console. -// For more information about adding event source types as a cluster administrator, see -// xref:../knative-client.adoc#knative-client[Installing Knative Client]. +API server source:: Connects a sink to the Kubernetes API server by creating an `APIServerSource` object. +Ping source:: Periodically sends ping events with a constant payload. It can be used as a timer, and is created as a `PingSource` object. include::modules/serverless-list-source-types.adoc[leveloffset=+1] include::modules/serverless-list-source.adoc[leveloffset=+1] == Next steps -* See the documentation on xref:../event_sources/serverless-apiserversource.adoc#serverless-apiserversource[Using ApiServerSource]. -* See the documentation on xref:../event_sources/serverless-pingsource.adoc#serverless-pingsource[Using PingSource]. +* See the documentation on xref:../event_sources/serverless-apiserversource.adoc#serverless-apiserversource[Using the API server source]. +* See the documentation on xref:../event_sources/serverless-pingsource.adoc#serverless-pingsource[Using a ping source]. diff --git a/serverless/event_sources/serverless-pingsource.adoc b/serverless/event_sources/serverless-pingsource.adoc index 39159d4c66c4..d022c8fd8d70 100644 --- a/serverless/event_sources/serverless-pingsource.adoc +++ b/serverless/event_sources/serverless-pingsource.adoc @@ -1,15 +1,15 @@ include::modules/serverless-document-attributes.adoc[] [id="serverless-pingsource"] -= Using a PingSource += Using a ping source :context: serverless-pingsource include::modules/common-attributes.adoc[] toc::[] -A PingSource is used to periodically send ping events with a constant payload to an event consumer. - -A PingSource can be used to schedule sending events, similar to a timer, as shown in the example: +A ping source is used to periodically send ping events with a constant payload to an event consumer. +A ping source can be used to schedule sending events, similar to a timer, as shown in the example: +.Example ping source ---- apiVersion: sources.knative.dev/v1alpha2 kind: PingSource @@ -24,7 +24,6 @@ spec: kind: Service name: event-display ---- - <1> The schedule of the event specified using https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/#schedule[CRON expression]. <2> The event message body expressed as a JSON encoded data string. <3> These are the details of the event consumer. In this example, we are using a Knative service named `event-display`.