[SRVCOM-1115] Updating OCP 4.5 serverless docs to new OCP guidelines

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 <trigger_name>
 ----
-
 . Delete the service:
 +
-
 [source,terminal]
 ----
 $ kn service delete <service_name>
 ----
-
-. Delete the event source:
+. Delete the API server source:
 +
-
 [source,terminal]
 ----
 $ kn source apiserver delete <source_name>
 ----
-
 . Delete the service account, cluster role, and cluster binding:
 
 [source,terminal]

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 <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
 ----
-
 . Create a Knative service that dumps incoming messages to its log:
 +
 [source,terminal]
 ----
 $ kn service create <service_name> --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 <trigger_name> --sink ksvc:<service_name>
 ----
-
-. 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

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

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,16 +89,14 @@ 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`:
 +
@@ -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

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 <service-name> --image <image> --env <key=value>
+$ kn service create <service_name> --image <image> --env <key=value>
 ----
 
 +

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