diff --git a/modules/apiserversource-kn-delete.adoc b/modules/apiserversource-kn-delete.adoc index 459a65e2a9fe..893a3b386292 100644 --- a/modules/apiserversource-kn-delete.adoc +++ b/modules/apiserversource-kn-delete.adoc @@ -3,40 +3,33 @@ // serverless/event_workflows/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 45ef1fdd3ca3..ac655763d21a 100644 --- a/modules/apiserversource-kn.adoc +++ b/modules/apiserversource-kn.adoc @@ -3,44 +3,99 @@ // serverless/event_workflows/serverless-listing-event-sources.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 must 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 an ApiServerSource that uses a broker as an event sink: +. 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 +kind: ServiceAccount +metadata: + name: events-sa + namespace: default <1> + +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + name: event-watcher + namespace: default <1> +rules: + - apiGroups: + - "" + resources: + - events + verbs: + - get + - list + - watch + +--- +apiVersion: rbac.authorization.k8s.io/v1 +kind: RoleBinding +metadata: + name: k8s-ra-event-watcher + namespace: default <1> +roleRef: + apiGroup: rbac.authorization.k8s.io + kind: Role + name: event-watcher +subjects: + - kind: ServiceAccount + name: events-sa + namespace: default <1> +---- ++ +<1> Change this namespace to the namespace that you have selected for installing the API server source. ++ +[NOTE] +==== +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` 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 ksvc: ---- - -. Create events by launching a Pod in the default namespace: +. 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] @@ -49,7 +104,6 @@ $ kn source apiserver describe testevents ---- + .Example output -+ [source,terminal] ---- Name: testevents @@ -84,7 +138,6 @@ You can verify that the Kubernetes events were sent to Knative by looking at the ---- $ oc get pods ---- - . View the message dumper function logs for the pods: + [source,terminal] @@ -93,8 +146,6 @@ $ 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 bb896c9e02e9..42047f63b7c3 100644 --- a/modules/apiserversource-yaml-delete.adoc +++ b/modules/apiserversource-yaml-delete.adoc @@ -3,39 +3,32 @@ // serverless/event_workflows/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 9559e753f382..c86b83617741 100644 --- a/modules/apiserversource-yaml.adoc +++ b/modules/apiserversource-yaml.adoc @@ -3,18 +3,18 @@ // * serverless/event_sources/serverless-apiserversource.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] ---- @@ -56,7 +56,7 @@ 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] ==== @@ -69,8 +69,7 @@ After you have created the `authentication.yaml` file, apply it: ---- $ 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] ---- @@ -90,7 +89,6 @@ spec: kind: Broker name: default ---- - + After you have created the `k8s-events.yaml` file, apply it: + @@ -98,8 +96,7 @@ After you have created the `k8s-events.yaml` file, apply it: ---- $ 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`: + @@ -123,7 +120,6 @@ After you have created the `service.yaml` file, apply it: ---- $ 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] @@ -148,14 +144,12 @@ After you have created the `trigger.yaml` file, apply it: ---- $ 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] @@ -164,7 +158,6 @@ $ oc get apiserversource.sources.knative.dev testevents -o yaml ---- + .Example output -+ [source,yaml] ---- apiVersion: sources.knative.dev/v1alpha1 @@ -208,7 +201,6 @@ To verify that the Kubernetes events were sent to Knative, you can look at the m ---- $ oc get pods ---- - . View the message dumper function logs for the pods: + [source,terminal] @@ -217,7 +209,6 @@ $ 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 41edfb16dbaf..349c9c335436 100644 --- a/modules/creating-serverless-apps-kn.adoc +++ b/modules/creating-serverless-apps-kn.adoc @@ -18,7 +18,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 ---- + diff --git a/modules/serverless-about-collecting-data.adoc b/modules/serverless-about-collecting-data.adoc index 77461eacdd07..4fb374200a63 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: ---- $ oc adm must-gather --image=registry.redhat.io/openshift-serverless-1/svls-must-gather-rhel8 diff --git a/modules/serverless-jaeger-config.adoc b/modules/serverless-jaeger-config.adoc index 7deb256ccfef..30ceee7dd3db 100644 --- a/modules/serverless-jaeger-config.adoc +++ b/modules/serverless-jaeger-config.adoc @@ -11,17 +11,14 @@ To configure Jaeger for use with {ServerlessProductName}, you will need: * 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 . Create and apply a Jaeger custom resource YAML file that contains the following sample YAML: + - .Jaeger custom resource YAML -+ - [source,terminal] ---- apiVersion: jaegertracing.io/v1 @@ -30,13 +27,9 @@ metadata: name: jaeger namespace: default ---- - . Enable tracing for Knative Serving, by editing the `KnativeServing` resource and adding a YAML configuration for tracing. + - .Tracing YAML example -+ - [source,yaml] ---- apiVersion: operator.knative.dev/v1alpha1 @@ -62,22 +55,17 @@ spec: Access the Jaeger web console to see tracing data. You can access the Jaeger web console by using the `jaeger` route. -. Get the `jaeger` route's hostname by entering the following command: +. Get the hostname of the `jaeger` route: + - [source,terminal] ---- $ oc get route jaeger ---- - + .Example output -+ - [source,terminal] ---- NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD jaeger jaeger-default.apps.example.com jaeger-query reencrypt None ---- - . Open the endpoint address in your browser to view the console. diff --git a/modules/serverless-list-source-types.adoc b/modules/serverless-list-source-types.adoc index 6408e4542da2..c89775a5edbe 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 @@ -35,6 +39,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 dc60648b5e51..7668fd97d71f 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 entering 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 ksvc:eshow3 Fa p1 PingSource pingsources.sources.knative.dev ksvc: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 1402485af668..aab7f3137280 100644 --- a/modules/serverless-metering-datasources.adoc +++ b/modules/serverless-metering-datasources.adoc @@ -3,13 +3,15 @@ [id="datasources-metering-serverless_{context}"] = Datasources for Knative Serving metering + The following `ReportDataSources` are examples of how Knative Serving can be used with {product-title} metering. [id="knative-service-cpu-usage-ds_{context}"] == Datasource for CPU usage in Knative Serving + This datasource provides the accumulated CPU seconds used per Knative service over the report time period. -.YAML file +.Example YAML file [source,yaml] ---- apiVersion: metering.openshift.io/v1 @@ -34,9 +36,10 @@ spec: [id="knative-service-memory-usage-ds_{context}"] == Datasource for memory usage in Knative Serving + This datasource provides the average memory consumption per Knative service over the report time period. -.YAML file +.Example YAML file [source,yaml] ---- apiVersion: metering.openshift.io/v1 @@ -60,12 +63,18 @@ spec: ---- [id="applying-datasources-knative_{context}"] -== Applying Datasources for Knative Serving metering -You can apply the `ReportDataSources` by using the following command: +== Applying data sources for Knative Serving metering + +.Procedure + +* Apply the `ReportDataSources` resource as a YAML file: ++ +[source,terminal] ---- -$ oc apply -f .yaml +$ oc apply -f .yaml ---- -.Example ++ +.Example command ---- $ oc apply -f knative-service-memory-usage.yaml ---- diff --git a/modules/serverless-metering-queries.adoc b/modules/serverless-metering-queries.adoc index 7961e7203599..bce170f0f591 100644 --- a/modules/serverless-metering-queries.adoc +++ b/modules/serverless-metering-queries.adoc @@ -3,13 +3,13 @@ [id="queries-metering-serverless_{context}"] = Queries for Knative Serving metering + The following `ReportQuery` resources reference the example `DataSources` provided. [id="knative-service-cpu-usage-query_{context}"] == Query for CPU usage in Knative Serving -.YAML file - +.Example YAML file [source,yaml] ---- apiVersion: metering.openshift.io/v1 @@ -64,8 +64,7 @@ spec: [id="knative-service-memory-usage-query_{context}"] == Query for memory usage in Knative Serving -.YAML file - +.Example YAML file [source,yaml] ---- apiVersion: metering.openshift.io/v1 @@ -118,20 +117,16 @@ spec: ---- [id="applying-queries-knative_{context}"] -== Applying Queries for Knative Serving metering +== Applying queries for Knative Serving metering -. Apply the `ReportQuery` by entering the following command: +* Apply the query as a YAML file: + - [source,terminal] ---- -$ oc apply -f .yaml +$ oc apply -f .yaml ---- - + .Example command -+ - [source,terminal] ---- $ oc apply -f knative-service-memory-usage.yaml diff --git a/modules/serverless-metering-reports.adoc b/modules/serverless-metering-reports.adoc index 1fef860171ac..ee98d9ab6003 100644 --- a/modules/serverless-metering-reports.adoc +++ b/modules/serverless-metering-reports.adoc @@ -7,8 +7,7 @@ You can run metering reports against Knative Serving by creating `Report` resources. Before you run a report, you must modify the input parameter within the `Report` resource to specify the start and end dates of the reporting period. -.YAML file - +.Example YAML file [source,yaml] ---- apiVersion: metering.openshift.io/v1 @@ -29,26 +28,20 @@ runImmediately: true [id="reports-metering-serverless-run_{context}"] == Running a metering report -. Run the report by entering the following command: +. Run the report by applying it as a YAML file: + - [source,terminal] ---- -$ oc apply -f .yml +$ oc apply -f .yaml ---- - . You can then check the report by entering the following command: + - [source,terminal] ---- $ oc get report ---- - + .Example output -+ - [source,terminal] ---- NAME QUERY SCHEDULE RUNNING FAILED LAST REPORT TIME AGE diff --git a/modules/serverless-pingsource-kn.adoc b/modules/serverless-pingsource-kn.adoc index 8d9b0d3f0873..df6b3bac1b66 100644 --- a/modules/serverless-pingsource-kn.adoc +++ b/modules/serverless-pingsource-kn.adoc @@ -3,9 +3,9 @@ // * serverless/event_workflows/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 ksvc: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 f6ddbc850e79..6d42caa2bab7 100644 --- a/modules/serverless-pingsource-yaml.adoc +++ b/modules/serverless-pingsource-yaml.adoc @@ -3,9 +3,9 @@ // * serverless/event_workflows/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 -service that dumps incoming messages to the service's logs. +. To verify that the ping source is working, create a simple Knative +service that dumps incoming messages to the log of the service. .. 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 0d0ec1c49a9a..fcd1663afb72 100644 --- a/modules/serverless-rn-1-7-0.adoc +++ b/modules/serverless-rn-1-7-0.adoc @@ -27,19 +27,17 @@ If you have installed a previous version of {ServerlessProductName}, after the K + 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 custom resources (CRs) without specifying an API group, for example, `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] ---- Revision "foo-1" failed with message: Unable to fetch image "image-registry.openshift-image-registry.svc:5000/eap/eap-app": failed to resolve image to digest: failed to fetch image information: Get https://image-registry.openshift-image-registry.svc:5000/v2/: x509: certificate signed by unknown authority. ---- - + The {ServerlessOperatorName} now restarts the Knative Serving controller whenever a new service CA certificate is generated, which ensures that the controller is always configured to use the current service CA certificate. For more information, see the {product-title} documentation on _Securing service traffic using service serving certificate secrets_ under _Authentication_. @@ -49,4 +47,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 will be a delay when you create the first new service after KnativeServing 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 c979cc253b96..4eb936cc5a44 100644 --- a/modules/verifying-serverless-app-deployment.adoc +++ b/modules/verifying-serverless-app-deployment.adoc @@ -9,18 +9,20 @@ 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 ` will always print 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 . Find the application URL by entering: + +[source,terminal] ---- -$ oc get ksvc hello +$ oc get ksvc ---- + .Example output +[source,terminal] ---- NAME URL LATESTCREATED LATESTREADY READY REASON hello http://hello-default.example.com hello-4wsd2 hello-4wsd2 True @@ -28,17 +30,22 @@ hello http://hello-default.example.com hello-4wsd2 hello-4wsd2 True . Make a request to your cluster and observe the output. + .Example HTTP request +[source,terminal] ---- $ curl http://hello-default.example.com -Hello Serverless! ---- + .Example HTTPS request +[source,terminal] ---- $ curl https://hello-default.example.com +---- ++ +.Example output +[source,terminal] +---- Hello Serverless! ---- - . Optional. If you receive an error relating to a self-signed certificate in the certificate chain, you can add the `--insecure` flag to the curl command to ignore the error. + [IMPORTANT] @@ -46,17 +53,28 @@ Hello Serverless! Self-signed certificates must not be used in a production deployment. This method is only for testing purposes. ==== + -.Example +.Example command +[source,terminal] ---- $ curl https://hello-default.example.com --insecure +---- ++ +.Example output +[source,terminal] +---- Hello Serverless! ---- - . Optional. If your {product-title} cluster is configured with a certificate that is signed by a certificate authority (CA) but not yet globally configured for your system, you can specify this with the curl command. The path to the certificate can be passed to the curl command by using the `--cacert` flag. + -.Example +.Example command +[source,terminal] ---- $ curl https://hello-default.example.com --cacert +---- ++ +.Example output +[source,terminal] +---- Hello Serverless! ---- diff --git a/serverless/architecture/serverless-event-architecture.adoc b/serverless/architecture/serverless-event-architecture.adoc index b42cb00d2a35..c0e132ed7997 100644 --- a/serverless/architecture/serverless-event-architecture.adoc +++ b/serverless/architecture/serverless-event-architecture.adoc @@ -18,14 +18,11 @@ You can propagate an event from an xref:../event_sources/knative-event-sources.a * xref:../event_workflows/serverless-using-brokers.adoc#serverless-using-brokers[brokers] 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 SinkBinding 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 will receive 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 +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. [id="serverless-event-architecture-sinks"] == Event sinks diff --git a/serverless/event_sources/knative-event-sources.adoc b/serverless/event_sources/knative-event-sources.adoc index ce91be0f690c..6117430e0f64 100644 --- a/serverless/event_sources/knative-event-sources.adoc +++ b/serverless/event_sources/knative-event-sources.adoc @@ -12,15 +12,16 @@ 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. -SinkBinding:: Allows you to connect core Kubernetes resource objects such as a `Deployment`, `Job`, or `StatefulSet` with a sink. +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. A ping source can be used as a timer, and is created as a `PingSource` object. + +xref:../../serverless/event_workflows/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. You can create and manage Knative event sources using the **Developer** perspective in the {product-title} web console, the `kn` CLI, or by applying YAML files. -* Create an xref:../../serverless/event_sources/serverless-apiserversource.adoc#serverless-apiserversource[ApiServerSource]. -* Create an xref:../../serverless/event_sources/serverless-pingsource.adoc#serverless-pingsource[PingSource]. -* Create a xref:../../serverless/event_workflows/serverless-sinkbinding.adoc#serverless-sinkbinding[SinkBinding]. +* Create an xref:../../serverless/event_sources/serverless-apiserversource.adoc#serverless-apiserversource[API server source]. +* Create a xref:../../serverless/event_sources/serverless-pingsource.adoc#serverless-pingsource[ping source]. +* Create a xref:../../serverless/event_workflows/serverless-sinkbinding.adoc#serverless-sinkbinding[sink binding]. [id="knative-event-sources-additional-resources"] == Additional resources diff --git a/serverless/event_sources/serverless-apiserversource.adoc b/serverless/event_sources/serverless-apiserversource.adoc index 1b7751b48d8e..92ca64f19571 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. == Prerequisites diff --git a/serverless/event_sources/serverless-kn-source.adoc b/serverless/event_sources/serverless-kn-source.adoc index 6ca221ef0345..f3b5fc10a593 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. A ping source 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:../serverless-apiserversource.adoc#serverless-apiserversource[Using ApiServerSource]. -* See the documentation on xref:../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`.