From e730861ae1cb3194d736fd457f3569a54e9c313d Mon Sep 17 00:00:00 2001
From: Scott Nichols <snichols@vmware.com>
Date: Mon, 6 Jul 2020 09:46:55 -0700
Subject: [PATCH 1/3] Update the getting start doc to introduce the sugar
 controller.

---
 docs/eventing/getting-started.md | 807 +++++++++++++++++--------------
 1 file changed, 456 insertions(+), 351 deletions(-)

diff --git a/docs/eventing/getting-started.md b/docs/eventing/getting-started.md
index c253c80fe9b..1c38a1317cd 100644
--- a/docs/eventing/getting-started.md
+++ b/docs/eventing/getting-started.md
@@ -5,7 +5,9 @@ weight: 9
 type: "docs"
 ---
 
-Use this guide to learn how to create, send, and verify events in Knative. The steps in this guide demonstrate a basic developer flow for managing events in Knative, including:
+Use this guide to learn how to create, send, and verify events in Knative. The
+steps in this guide demonstrate a basic developer flow for managing events in
+Knative, including:
 
 1. [Installing the Knative Eventing component](#installing-knative-eventing)
 
@@ -19,9 +21,12 @@ Use this guide to learn how to create, send, and verify events in Knative. The s
 
 To complete this guide, you will need the following installed and running:
 
-- A [Kubernetes cluster](https://kubernetes.io/docs/concepts/cluster-administration/cluster-administration-overview/) running v1.15 or higher.
+- A
+  [Kubernetes cluster](https://kubernetes.io/docs/concepts/cluster-administration/cluster-administration-overview/)
+  running v1.15 or higher.
 
-- [`kubectl` CLI tool](https://kubernetes.io/docs/reference/kubectl/overview/) within a minor version of your Kubernetes cluster.
+- [`kubectl` CLI tool](https://kubernetes.io/docs/reference/kubectl/overview/)
+  within a minor version of your Kubernetes cluster.
 
 - [curl v7.65 or higher](https://curl.haxx.se/download.html).
 
@@ -29,289 +34,364 @@ To complete this guide, you will need the following installed and running:
 
   - Knative Eventing in-memory channel.
 
-**Important Note:** Some Knative Eventing features do not work when using Minikube due to [this](https://github.com/kubernetes/minikube/issues/1568) bug. For local testing you can use [kind](https://github.com/kubernetes-sigs/kind).
-
+**Important Note:** Some Knative Eventing features do not work when using
+Minikube due to [this](https://github.com/kubernetes/minikube/issues/1568) bug.
+For local testing you can use [kind](https://github.com/kubernetes-sigs/kind).
 
 ### Installing Knative Eventing
 
-If you previously [created a Knative cluster](../install), you might already have Knative Eventing installed and running. You can check to see if the Eventing component exists on your cluster by running:
+If you previously [created a Knative cluster](../install), you might already
+have Knative Eventing installed and running. You can check to see if the
+Eventing component exists on your cluster by running:
 
 ```sh
 kubectl get pods --namespace knative-eventing
 ```
 
-If the `knative-eventing` namespace or the `imc-controller-*` does not exist, use the following steps to install Knative Eventing with the in-memory channel:
+If the `knative-eventing` namespace or the `imc-controller-*` does not exist,
+use the following steps to install Knative Eventing with the in-memory channel:
 
-1. Make sure that you have a functioning Kubernetes cluster. See the [Comprehensive Install guide](../install) for more information.
+1. Make sure that you have a functioning Kubernetes cluster. See the
+   [Comprehensive Install guide](../install) for more information.
 
-   - Old versions of Knative Serving doesn't necessarily work well with latest Knative Eventing, so try to install the latest version of Knative Serving.
+   - Old versions of Knative Serving doesn't necessarily work well with latest
+     Knative Eventing, so try to install the latest version of Knative Serving.
 
-   - If your Kubernetes cluster comes with pre-installed Istio, make sure it has `cluster-local-gateway` [deployed](https://github.com/knative/serving/blob/master/DEVELOPMENT.md#deploy-istio). Depending on which Istio version you have, you'd need to apply the `istio-knative-extras.yaml` in the corresponding version folder at [here](https://github.com/knative/serving/tree/{{< branch >}}/third_party).
+   - If your Kubernetes cluster comes with pre-installed Istio, make sure it has
+     `cluster-local-gateway`
+     [deployed](https://github.com/knative/serving/blob/master/DEVELOPMENT.md#deploy-istio).
+     Depending on which Istio version you have, you'd need to apply the
+     `istio-knative-extras.yaml` in the corresponding version folder at
+     [here](https://github.com/knative/serving/tree/{{< branch >}}/third_party).
 
 1. Install the Eventing CRDs by running the following command:
 
-    ```sh
-    kubectl apply --selector knative.dev/crd-install=true \
-    --filename {{< artifact repo="eventing" file="eventing.yaml" >}}
-    ```
+   ```sh
+   kubectl apply --selector knative.dev/crd-install=true \
+   --filename {{< artifact repo="eventing" file="eventing.yaml" >}}
+   ```
 
 1. Finish installing Eventing resources by running the following command:
 
-    ```sh
-    kubectl apply --filename {{< artifact repo="eventing" file="eventing.yaml" >}}
-    ```
+   ```sh
+   kubectl apply --filename {{< artifact repo="eventing" file="eventing.yaml" >}}
+   ```
 
-   Installing the CRDs first can prevent race conditions, which might cause failures during the install.
-   Race conditions exist during install because a CRD must be defined before an instance of that
-   resource can be created. Defining all CRDs before continuing with the rest of the installation
+   Installing the CRDs first can prevent race conditions, which might cause
+   failures during the install. Race conditions exist during install because a
+   CRD must be defined before an instance of that resource can be created.
+   Defining all CRDs before continuing with the rest of the installation
    prevents this problem.
 
-1. Confirm that Knative Eventing is correctly installed by running the following command:
-
-    ```sh
-    kubectl get pods --namespace knative-eventing
-    ```
-    This will return the following result:
-
-    ```sh
-    NAME                                    READY   STATUS    RESTARTS   AGE
-    broker-controller-56b4d58667-fm979      1/1     Running   0          4m36s
-    broker-filter-5bdbc8d8dd-kpswx          1/1     Running   0          4m35s
-    broker-ingress-d896b6b46-4nbtr          1/1     Running   0          4m35s
-    eventing-controller-5fc5645584-qvspl    1/1     Running   0          4m36s
-    eventing-webhook-7674b867dc-zw9qh       1/1     Running   0          4m36s
-    imc-controller-6b548d6468-gnbkn         1/1     Running   0          4m35s
-    imc-dispatcher-655cdf6ff6-mkc29         1/1     Running   0          4m35s
-    mt-broker-controller-6d66c4c6f6-xdn7b   1/1     Running   0          4m35s
+1. Confirm that Knative Eventing is correctly installed by running the following
+   command:
+
+   ```sh
+   kubectl get pods --namespace knative-eventing
    ```
 
-## Setting up Knative Eventing Resources
+   This will return the following result:
+
+   ```sh
+   NAME                                    READY   STATUS    RESTARTS   AGE
+   broker-controller-56b4d58667-fm979      1/1     Running   0          4m36s
+   broker-filter-5bdbc8d8dd-kpswx          1/1     Running   0          4m35s
+   broker-ingress-d896b6b46-4nbtr          1/1     Running   0          4m35s
+   eventing-controller-5fc5645584-qvspl    1/1     Running   0          4m36s
+   eventing-webhook-7674b867dc-zw9qh       1/1     Running   0          4m36s
+   imc-controller-6b548d6468-gnbkn         1/1     Running   0          4m35s
+   imc-dispatcher-655cdf6ff6-mkc29         1/1     Running   0          4m35s
+   mt-broker-controller-6d66c4c6f6-xdn7b   1/1     Running   0          4m35s
+   ```
 
-Before you start to manage events, you need to create the objects needed to transport the events.
+## Setting up Knative Eventing Resources
 
+Before you start to manage events, you need to create the objects needed to
+transport the events.
 
 ### Creating and configuring an Eventing namespace
 
-In this section you create the `event-example` namespace and then add the `knative-eventing-injection` label to that namespace. You use namespaces to group together and organize your Knative resources, including the Eventing subcomponents.
+In this section you create the `event-example` namespace and add a Broker to
+that namespace. You use namespaces to group together and organize your Knative
+resources, including the Eventing subcomponents.
 
 1. Run the following command to create a namespace called `event-example`:
 
-    ```sh
-    kubectl create namespace event-example
-    ```
+   ```sh
+   kubectl create namespace event-example
+   ```
+
+   This creates an empty namespace called `event-example`.
+
+1. Add a Broker named `default` to your namespace with the following command:
 
-    This creates an empty namespace called `event-example`.
+   ```sh
+   kubectl create -f - <<EOF
+   apiVersion: eventing.knative.dev/v1
+   kind: Broker
+   metadata:
+     name: default
+     namespace: event-example
+   EOF
+   ```
+
+   This creates the default Broker for the namespace based on config. The Broker
+   is a resource that will allow you to manage your events.
+
+In the next section, you will need to verify that the resources you added in
+this section are running correctly. Then, you can create the rest of the
+eventing resources you need to manage events.
 
-1. Add a label to your namespace with the following command:
+#### Optional Sugar Controller
 
-    ```sh
-    kubectl label namespace event-example knative-eventing-injection=enabled
-    ```
+When installed, the [Sugar Controller for Knative Eventing](TODO:: Link TBD)
+will add a controller that reacts to special labels and annotations for your
+resources, you can skip manually creating a Broker in the above step and instead
+label a namespace:
 
-   This gives the `event-example`  namespace the `knative-eventing-injection` label, which adds resources that will allow you to manage your events.
+```sh
+kubectl label namespace event-example eventing.knative.dev/injection=enabled
+```
 
-In the next section, you will need to verify that the resources you added in this section are running correctly. Then, you can create the rest of the eventing resources you need to manage events.
+This gives the `event-example` namespace the `eventing.knative.dev/injection`
+label, which adds resources that will allow you to manage your events.
 
 ### Validating that the `Broker` is running
 
-The [`Broker`](./broker/README.md#broker) ensures that every event sent by event producers arrives at the correct event consumers. The `Broker` was created when you labeled your namespace as ready for eventing, but it is important to verify that your `Broker` is working correctly. In this guide, you will use the default broker.
+The [`Broker`](./broker/README.md#broker) ensures that every event sent by event
+producers arrives at the correct event consumers. The `Broker` was created when
+you labeled your namespace as ready for eventing, but it is important to verify
+that your `Broker` is working correctly. In this guide, you will use the default
+broker.
 
 1. Run the following command to verify that the `Broker` is in a healthy state:
 
-    ```sh
-    kubectl --namespace event-example get Broker default
-    ```
+   ```sh
+   kubectl --namespace event-example get Broker default
+   ```
 
    This shows the `Broker` that you created:
 
-    ```sh
-    NAME      READY   REASON   URL                                                        AGE
-    default   True             http://default-broker.event-example.svc.cluster.local      1m
-    ```
+   ```sh
+   NAME      READY   REASON   URL                                                        AGE
+   default   True             http://default-broker.event-example.svc.cluster.local      1m
+   ```
 
-    When the `Broker` has the `READY=True` state, it can begin to manage any events it receives.
+   When the `Broker` has the `READY=True` state, it can begin to manage any
+   events it receives.
 
-1. If `READY=False`, wait 2 minutes and re-run the command. If you continue to receive the `READY=False`, see the [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
+1. If `READY=False`, wait 2 minutes and re-run the command. If you continue to
+   receive the `READY=False`, see the [Debugging Guide](./debugging/README.md)
+   to help troubleshoot the issue.
 
-Now that your `Broker` is ready to manage events, you can create and configure your event producers and consumers.
+Now that your `Broker` is ready to manage events, you can create and configure
+your event producers and consumers.
 
 ### Creating event consumers
 
-Your event consumers receive the events sent by event producers. In this step, you will create two event consumers, `hello-display` and `goodbye-display`, to demonstrate how you can configure your event producers to selectively target a specific consumer.
-
-1. To deploy the `hello-display` consumer to your cluster, run the following command:
-
-    ```sh
-    kubectl --namespace event-example apply --filename - << END
-    apiVersion: apps/v1
-    kind: Deployment
-    metadata:
-      name: hello-display
-    spec:
-      replicas: 1
-      selector:
-        matchLabels: &labels
-          app: hello-display
-      template:
-        metadata:
-          labels: *labels
-        spec:
-          containers:
-            - name: event-display
-              # Source code: https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
-              image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
-
-    ---
-
-    # Service pointing at the previous Deployment. This will be the target for event
-    # consumption.
-      kind: Service
-      apiVersion: v1
-      metadata:
-        name: hello-display
-      spec:
-        selector:
-          app: hello-display
-        ports:
-        - protocol: TCP
-          port: 80
-          targetPort: 8080
-    END
-    ```
-
-1. To deploy the `goodbye-display` consumer to your cluster, run the following command:
-
-    ```sh
-    kubectl --namespace event-example apply --filename - << END
-    apiVersion: apps/v1
-    kind: Deployment
-    metadata:
-      name: goodbye-display
-    spec:
-      replicas: 1
-      selector:
-        matchLabels: &labels
-          app: goodbye-display
-      template:
-        metadata:
-          labels: *labels
-        spec:
-          containers:
-            - name: event-display
-              # Source code: https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
-              image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
-
-    ---
-
-    # Service pointing at the previous Deployment. This will be the target for event
-    # consumption.
-    kind: Service
-    apiVersion: v1
-    metadata:
-      name: goodbye-display
-    spec:
-      selector:
-        app: goodbye-display
-      ports:
-      - protocol: TCP
-        port: 80
-        targetPort: 8080
-    END
-    ```
-
-1. Just like you did with the `Broker`, verify that your event consumers are working by running the following command:
-
-    ```sh
-    kubectl --namespace event-example get deployments hello-display goodbye-display
-    ```
-
-    This lists the `hello-display` and `goodbye-display` consumers that you deployed:
-
-    ```sh
-    NAME              READY   UP-TO-DATE   AVAILABLE   AGE
-    hello-display     1/1     1            1           26s
-    goodbye-display   1/1     1            1           16s
+Your event consumers receive the events sent by event producers. In this step,
+you will create two event consumers, `hello-display` and `goodbye-display`, to
+demonstrate how you can configure your event producers to selectively target a
+specific consumer.
+
+1. To deploy the `hello-display` consumer to your cluster, run the following
+   command:
+
+   ```sh
+   kubectl --namespace event-example apply --filename - << END
+   apiVersion: apps/v1
+   kind: Deployment
+   metadata:
+     name: hello-display
+   spec:
+     replicas: 1
+     selector:
+       matchLabels: &labels
+         app: hello-display
+     template:
+       metadata:
+         labels: *labels
+       spec:
+         containers:
+           - name: event-display
+             # Source code: https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
+             image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
+
+   ---
+
+   # Service pointing at the previous Deployment. This will be the target for event
+   # consumption.
+     kind: Service
+     apiVersion: v1
+     metadata:
+       name: hello-display
+     spec:
+       selector:
+         app: hello-display
+       ports:
+       - protocol: TCP
+         port: 80
+         targetPort: 8080
+   END
    ```
 
-    The number of replicas in your **READY** column should match the number of replicas in your **AVAILABLE** column, which might take a few minutes. If after two minutes the numbers do not match, then see the [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
+1. To deploy the `goodbye-display` consumer to your cluster, run the following
+   command:
+
+   ```sh
+   kubectl --namespace event-example apply --filename - << END
+   apiVersion: apps/v1
+   kind: Deployment
+   metadata:
+     name: goodbye-display
+   spec:
+     replicas: 1
+     selector:
+       matchLabels: &labels
+         app: goodbye-display
+     template:
+       metadata:
+         labels: *labels
+       spec:
+         containers:
+           - name: event-display
+             # Source code: https://github.com/knative/eventing-contrib/tree/master/cmd/event_display
+             image: gcr.io/knative-releases/knative.dev/eventing-contrib/cmd/event_display
+
+   ---
+
+   # Service pointing at the previous Deployment. This will be the target for event
+   # consumption.
+   kind: Service
+   apiVersion: v1
+   metadata:
+     name: goodbye-display
+   spec:
+     selector:
+       app: goodbye-display
+     ports:
+     - protocol: TCP
+       port: 80
+       targetPort: 8080
+   END
+   ```
 
-### Creating `Triggers`
+1. Just like you did with the `Broker`, verify that your event consumers are
+   working by running the following command:
 
-A [Trigger](./broker/README.md#trigger) defines the events that you want each of your event consumers
-to receive. Your `Broker` uses triggers to forward events to the right consumers. Each trigger can specify a filter to select relevant events based on the Cloud Event context attributes.
+   ```sh
+   kubectl --namespace event-example get deployments hello-display goodbye-display
+   ```
+
+   This lists the `hello-display` and `goodbye-display` consumers that you
+   deployed:
+
+   ```sh
+   NAME              READY   UP-TO-DATE   AVAILABLE   AGE
+   hello-display     1/1     1            1           26s
+   goodbye-display   1/1     1            1           16s
+   ```
+
+   The number of replicas in your **READY** column should match the number of
+   replicas in your **AVAILABLE** column, which might take a few minutes. If
+   after two minutes the numbers do not match, then see the
+   [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
 
+### Creating `Triggers`
+
+A [Trigger](./broker/README.md#trigger) defines the events that you want each of
+your event consumers to receive. Your `Broker` uses triggers to forward events
+to the right consumers. Each trigger can specify a filter to select relevant
+events based on the Cloud Event context attributes.
 
 1. To create the first `Trigger`, run the following command:
 
-    ```sh
-    kubectl --namespace event-example apply --filename - << END
-    apiVersion: eventing.knative.dev/v1alpha1
-    kind: Trigger
-    metadata:
-      name: hello-display
-    spec:
-      broker: default
-      filter:
-        attributes:
-          type: greeting
-      subscriber:
-        ref:
-         apiVersion: v1
-         kind: Service
-         name: hello-display
-    END
-    ```
-
-   The command creates a trigger that sends all events of type `greeting` to your event consumer named `hello-display`.
+   ```sh
+   kubectl --namespace event-example apply --filename - << END
+   apiVersion: eventing.knative.dev/v1alpha1
+   kind: Trigger
+   metadata:
+     name: hello-display
+   spec:
+     broker: default
+     filter:
+       attributes:
+         type: greeting
+     subscriber:
+       ref:
+        apiVersion: v1
+        kind: Service
+        name: hello-display
+   END
+   ```
+
+   The command creates a trigger that sends all events of type `greeting` to
+   your event consumer named `hello-display`.
 
 1. To add the second `Trigger`, run the following command:
 
-    ```sh
-    kubectl --namespace event-example apply --filename - << END
-    apiVersion: eventing.knative.dev/v1alpha1
-    kind: Trigger
-    metadata:
-      name: goodbye-display
-    spec:
-      broker: default
-      filter:
-        attributes:
-          source: sendoff
-      subscriber:
-        ref:
-         apiVersion: v1
-         kind: Service
-         name: goodbye-display
-    END
-    ```
-
-   The command creates a trigger that sends all events of source `sendoff` to your event consumer named `goodbye-display`.
-
-1. Verify that the triggers are working correctly by running the following command:
-
-    ```sh
-    kubectl --namespace event-example get triggers
-    ```
-
-    This returns the `hello-display` and `goodbye-display` triggers that you created:
-
-    ```sh
-    NAME                   READY   REASON   BROKER    SUBSCRIBER_URI                                                                 AGE
-    goodbye-display        True             default   http://goodbye-display.event-example.svc.cluster.local/                        9s
-    hello-display          True             default   http://hello-display.event-example.svc.cluster.local/                          16s
-    ```
-
-    If the triggers are correctly configured, they will be ready and pointing to the correct **Broker** (the default broker)  and **SUBSCRIBER_URI** (triggerName.namespaceName.svc.cluster.local). If this is not the case, see the [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
-
-You have now created all of the resources needed to receive and manage events. You created the `Broker`, which manages the events sent to event consumers with the help of triggers.  In the next section, you will make the event producer that will be used to create your events.
+   ```sh
+   kubectl --namespace event-example apply --filename - << END
+   apiVersion: eventing.knative.dev/v1alpha1
+   kind: Trigger
+   metadata:
+     name: goodbye-display
+   spec:
+     broker: default
+     filter:
+       attributes:
+         source: sendoff
+     subscriber:
+       ref:
+        apiVersion: v1
+        kind: Service
+        name: goodbye-display
+   END
+   ```
+
+   The command creates a trigger that sends all events of source `sendoff` to
+   your event consumer named `goodbye-display`.
+
+1. Verify that the triggers are working correctly by running the following
+   command:
+
+   ```sh
+   kubectl --namespace event-example get triggers
+   ```
+
+   This returns the `hello-display` and `goodbye-display` triggers that you
+   created:
+
+   ```sh
+   NAME                   READY   REASON   BROKER    SUBSCRIBER_URI                                                                 AGE
+   goodbye-display        True             default   http://goodbye-display.event-example.svc.cluster.local/                        9s
+   hello-display          True             default   http://hello-display.event-example.svc.cluster.local/                          16s
+   ```
+
+   If the triggers are correctly configured, they will be ready and pointing to
+   the correct **Broker** (the default broker) and **SUBSCRIBER_URI**
+   (triggerName.namespaceName.svc.cluster.local). If this is not the case, see
+   the [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
+
+You have now created all of the resources needed to receive and manage events.
+You created the `Broker`, which manages the events sent to event consumers with
+the help of triggers. In the next section, you will make the event producer that
+will be used to create your events.
 
 ### Creating event producers
 
-In this section you will create an event producer that you can use to interact with the Knative Eventing subcomponents you created earlier. Most events are created systematically, but this guide uses `curl` to manually send individual events and demonstrate how these events are received by the correct event consumer. Because you can only access the `Broker` from within your Eventing cluster, you must create a `Pod` within that cluster to act as your event producer.
+In this section you will create an event producer that you can use to interact
+with the Knative Eventing subcomponents you created earlier. Most events are
+created systematically, but this guide uses `curl` to manually send individual
+events and demonstrate how these events are received by the correct event
+consumer. Because you can only access the `Broker` from within your Eventing
+cluster, you must create a `Pod` within that cluster to act as your event
+producer.
 
-In the following step, you will create a `Pod` that executes your `curl` commands to send events to the `Broker` in your Eventing cluster.
+In the following step, you will create a `Pod` that executes your `curl`
+commands to send events to the `Broker` in your Eventing cluster.
 
- To create the `Pod`, run the following command:
+To create the `Pod`, run the following command:
 
 ```sh
 kubectl --namespace event-example apply --filename - << END
@@ -335,17 +415,21 @@ spec:
 END
 ```
 
-Now that you've set up your Eventing cluster to send and consume events, you will use HTTP requests to manually send separate events and demonstrate how each of those events can target your individual event consumers in the next section.
+Now that you've set up your Eventing cluster to send and consume events, you
+will use HTTP requests to manually send separate events and demonstrate how each
+of those events can target your individual event consumers in the next section.
 
 ## Sending Events to the `Broker`
 
-Now that you've created the Pod, you can create an event by sending an HTTP request to the `Broker`. SSH into the `Pod` by running the following command:
+Now that you've created the Pod, you can create an event by sending an HTTP
+request to the `Broker`. SSH into the `Pod` by running the following command:
 
 ```sh
   kubectl --namespace event-example attach curl -it
 ```
 
- You have sshed into the Pod, and can now make an HTTP request. A prompt similar to the one below will appear:
+You have sshed into the Pod, and can now make an HTTP request. A prompt similar
+to the one below will appear:
 
 ```sh
     Defaulting container name to curl.
@@ -356,107 +440,164 @@ Now that you've created the Pod, you can create an event by sending an HTTP requ
 
 To show the various types of events you can send, you will make three requests:
 
-1. To make the first request, which creates an event that has the `type` `greeting`, run the following in the SSH terminal:
-
-    ```sh
-    curl -v "http://default-broker.event-example.svc.cluster.local" \
-      -X POST \
-      -H "Ce-Id: say-hello" \
-      -H "Ce-Specversion: 1.0" \
-      -H "Ce-Type: greeting" \
-      -H "Ce-Source: not-sendoff" \
-      -H "Content-Type: application/json" \
-      -d '{"msg":"Hello Knative!"}'
-    ```
-
-    When the `Broker` receives your event, `hello-display` will activate and send it to the event consumer of the same name.
-
-    If the event has been received, you will receive a `202 Accepted` response similar to the one below:
-
-    ```sh
-    < HTTP/1.1 202 Accepted
-    < Content-Length: 0
-    < Date: Mon, 12 Aug 2019 19:48:18 GMT
-    ```
-
-
-1. To make the second request, which creates an event that has the `source` `sendoff`, run the following in the SSH terminal:
-
-    ```sh
-    curl -v "http://default-broker.event-example.svc.cluster.local" \
-      -X POST \
-      -H "Ce-Id: say-goodbye" \
-      -H "Ce-Specversion: 1.0" \
-      -H "Ce-Type: not-greeting" \
-      -H "Ce-Source: sendoff" \
-      -H "Content-Type: application/json" \
-      -d '{"msg":"Goodbye Knative!"}'
-    ```
-
-   When the `Broker` receives your event, `goodbye-display` will activate and send the event to the event consumer of the same name.
-
-   If the event has been received, you will receive a `202 Accepted` response similar to the one below:
-
-    ```sh
-    < HTTP/1.1 202 Accepted
-    < Content-Length: 0
-    < Date: Mon, 12 Aug 2019 19:48:18 GMT
-    ```
-
-1. To make the third request, which creates an event that has the `type` `greeting` and the`source` `sendoff`, run the following in the SSH terminal:
-
-    ```sh
-    curl -v "http://default-broker.event-example.svc.cluster.local" \
-      -X POST \
-      -H "Ce-Id: say-hello-goodbye" \
-      -H "Ce-Specversion: 1.0" \
-      -H "Ce-Type: greeting" \
-      -H "Ce-Source: sendoff" \
-      -H "Content-Type: application/json" \
-      -d '{"msg":"Hello Knative! Goodbye Knative!"}'
+1. To make the first request, which creates an event that has the `type`
+   `greeting`, run the following in the SSH terminal:
+
+   ```sh
+   curl -v "http://default-broker.event-example.svc.cluster.local" \
+     -X POST \
+     -H "Ce-Id: say-hello" \
+     -H "Ce-Specversion: 1.0" \
+     -H "Ce-Type: greeting" \
+     -H "Ce-Source: not-sendoff" \
+     -H "Content-Type: application/json" \
+     -d '{"msg":"Hello Knative!"}'
+   ```
+
+   When the `Broker` receives your event, `hello-display` will activate and send
+   it to the event consumer of the same name.
+
+   If the event has been received, you will receive a `202 Accepted` response
+   similar to the one below:
+
+   ```sh
+   < HTTP/1.1 202 Accepted
+   < Content-Length: 0
+   < Date: Mon, 12 Aug 2019 19:48:18 GMT
+   ```
+
+1) To make the second request, which creates an event that has the `source`
+   `sendoff`, run the following in the SSH terminal:
+
+   ```sh
+   curl -v "http://default-broker.event-example.svc.cluster.local" \
+     -X POST \
+     -H "Ce-Id: say-goodbye" \
+     -H "Ce-Specversion: 1.0" \
+     -H "Ce-Type: not-greeting" \
+     -H "Ce-Source: sendoff" \
+     -H "Content-Type: application/json" \
+     -d '{"msg":"Goodbye Knative!"}'
+   ```
+
+   When the `Broker` receives your event, `goodbye-display` will activate and
+   send the event to the event consumer of the same name.
+
+   If the event has been received, you will receive a `202 Accepted` response
+   similar to the one below:
+
+   ```sh
+   < HTTP/1.1 202 Accepted
+   < Content-Length: 0
+   < Date: Mon, 12 Aug 2019 19:48:18 GMT
    ```
 
-   When the `Broker` receives your event,  `hello-display` and `goodbye-display` will activate and send the event to the event consumer of the same name.
+1) To make the third request, which creates an event that has the `type`
+   `greeting` and the`source` `sendoff`, run the following in the SSH terminal:
+
+   ```sh
+   curl -v "http://default-broker.event-example.svc.cluster.local" \
+     -X POST \
+     -H "Ce-Id: say-hello-goodbye" \
+     -H "Ce-Specversion: 1.0" \
+     -H "Ce-Type: greeting" \
+     -H "Ce-Source: sendoff" \
+     -H "Content-Type: application/json" \
+     -d '{"msg":"Hello Knative! Goodbye Knative!"}'
+   ```
 
-   If the event has been received, you will receive a `202 Accepted` response similar to the one below:
+   When the `Broker` receives your event, `hello-display` and `goodbye-display`
+   will activate and send the event to the event consumer of the same name.
 
-    ```sh
-    < HTTP/1.1 202 Accepted
-    < Content-Length: 0
-    < Date: Mon, 12 Aug 2019 19:48:18 GMT
-    ```
+   If the event has been received, you will receive a `202 Accepted` response
+   similar to the one below:
 
-4. Exit SSH by typing `exit` into the command prompt.
+   ```sh
+   < HTTP/1.1 202 Accepted
+   < Content-Length: 0
+   < Date: Mon, 12 Aug 2019 19:48:18 GMT
+   ```
 
-You have sent two events to the `hello-display` event consumer and two events to the `goodbye-display` event consumer (note that `say-hello-goodbye` activates the trigger conditions for *both* `hello-display` and `goodbye-display`). You will verify that these events were received correctly in the next section.
+1) Exit SSH by typing `exit` into the command prompt.
+
+You have sent two events to the `hello-display` event consumer and two events to
+the `goodbye-display` event consumer (note that `say-hello-goodbye` activates
+the trigger conditions for _both_ `hello-display` and `goodbye-display`). You
+will verify that these events were received correctly in the next section.
 
 ## Verifying events were received
 
-After sending events, verify that your events were received by the appropriate `Subscribers`.
+After sending events, verify that your events were received by the appropriate
+`Subscribers`.
 
-1. Look at the logs for the `hello-display` event consumer by running the following command:
+1. Look at the logs for the `hello-display` event consumer by running the
+   following command:
 
-    ```sh
-    kubectl --namespace event-example logs -l app=hello-display --tail=100
-    ```
+   ```sh
+   kubectl --namespace event-example logs -l app=hello-display --tail=100
+   ```
 
-    This returns the `Attributes` and `Data` of the events you sent to `hello-display`:
+   This returns the `Attributes` and `Data` of the events you sent to
+   `hello-display`:
+
+   ```sh
+   ☁️  cloudevents.Event
+   Validation: valid
+   Context Attributes,
+     specversion: 1.0
+     type: greeting
+     source: not-sendoff
+     id: say-hello
+     time: 2019-05-20T17:59:43.81718488Z
+     contenttype: application/json
+   Extensions,
+     knativehistory: default-broker-srk54-channel-24gls.event-example.svc.cluster.local
+   Data,
+     {
+       "msg": "Hello Knative!"
+     }
+   ☁️  cloudevents.Event
+   Validation: valid
+   Context Attributes,
+     specversion: 1.0
+     type: greeting
+     source: sendoff
+     id: say-hello-goodbye
+     time: 2019-05-20T17:59:54.211866425Z
+     contenttype: application/json
+   Extensions,
+     knativehistory: default-broker-srk54-channel-24gls.event-example.svc.cluster.local
+   Data,
+    {
+      "msg": "Hello Knative! Goodbye Knative!"
+    }
+   ```
 
-    ```sh
-    ☁️  cloudevents.Event
-    Validation: valid
-    Context Attributes,
+1. Look at the logs for the `goodbye-display` event consumer by running the
+   following command:
+
+   ```sh
+   kubectl --namespace event-example logs -l app=goodbye-display --tail=100
+   ```
+
+   This returns the `Attributes` and `Data` of the events you sent to
+   `goodbye-display`:
+
+   ```sh
+   ☁️  cloudevents.Event
+   Validation: valid
+   Context Attributes,
       specversion: 1.0
-      type: greeting
-      source: not-sendoff
-      id: say-hello
-      time: 2019-05-20T17:59:43.81718488Z
+      type: not-greeting
+      source: sendoff
+      id: say-goodbye
+      time: 2019-05-20T17:59:49.044926148Z
       contenttype: application/json
     Extensions,
       knativehistory: default-broker-srk54-channel-24gls.event-example.svc.cluster.local
-    Data,
+   Data,
       {
-        "msg": "Hello Knative!"
+        "msg": "Goodbye Knative!"
       }
     ☁️  cloudevents.Event
     Validation: valid
@@ -473,54 +614,17 @@ After sending events, verify that your events were received by the appropriate `
      {
        "msg": "Hello Knative! Goodbye Knative!"
      }
-    ```
-
-1. Look at the logs for the `goodbye-display` event consumer by running the following command:
-
-    ```sh
-    kubectl --namespace event-example logs -l app=goodbye-display --tail=100
-    ```
-
-    This returns the `Attributes` and `Data` of the events you sent to `goodbye-display`:
-
-    ```sh
-    ☁️  cloudevents.Event
-    Validation: valid
-    Context Attributes,
-       specversion: 1.0
-       type: not-greeting
-       source: sendoff
-       id: say-goodbye
-       time: 2019-05-20T17:59:49.044926148Z
-       contenttype: application/json
-     Extensions,
-       knativehistory: default-broker-srk54-channel-24gls.event-example.svc.cluster.local
-    Data,
-       {
-         "msg": "Goodbye Knative!"
-       }
-     ☁️  cloudevents.Event
-     Validation: valid
-     Context Attributes,
-       specversion: 1.0
-       type: greeting
-       source: sendoff
-       id: say-hello-goodbye
-       time: 2019-05-20T17:59:54.211866425Z
-       contenttype: application/json
-     Extensions,
-       knativehistory: default-broker-srk54-channel-24gls.event-example.svc.cluster.local
-     Data,
-      {
-        "msg": "Hello Knative! Goodbye Knative!"
-      }
    ```
 
 ## Cleaning up
 
-After you finish this guide, delete your namespace to conserve resources if you do not plan to use them.
+After you finish this guide, delete your namespace to conserve resources if you
+do not plan to use them.
 
-Note: If you plan to continue learning about Knative Eventing with one of our [code samples](./samples/), check the requirements of the sample and make sure you do not need a namespace before you delete `event-example`. You can always reuse your namespaces.
+Note: If you plan to continue learning about Knative Eventing with one of our
+[code samples](./samples/), check the requirements of the sample and make sure
+you do not need a namespace before you delete `event-example`. You can always
+reuse your namespaces.
 
 Run the following command to delete `event-example`:
 
@@ -530,10 +634,11 @@ kubectl delete namespace event-example
 
 This removes the namespace and all of its resources from your cluster.
 
-
 ## What’s next
 
-You've learned the basics of the Knative Eventing workflow. Here are some additional resources to help you continue to build with the Knative Eventing component.
+You've learned the basics of the Knative Eventing workflow. Here are some
+additional resources to help you continue to build with the Knative Eventing
+component.
 
 - [Broker and Trigger](./broker/README.md)
 - [Eventing with a GitHub source](./samples/github-source/README.md)

From 7cbdf244f6633c6f9f06a8a08a22c1b8c9d7fcfa Mon Sep 17 00:00:00 2001
From: Scott Nichols <snichols@vmware.com>
Date: Mon, 6 Jul 2020 10:06:42 -0700
Subject: [PATCH 2/3] adding install instructions for sugar controller

---
 docs/eventing/getting-started.md       |  2 +-
 docs/install/any-kubernetes-cluster.md | 19 ++++++++++++++++---
 2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/docs/eventing/getting-started.md b/docs/eventing/getting-started.md
index 1c38a1317cd..796575ed87c 100644
--- a/docs/eventing/getting-started.md
+++ b/docs/eventing/getting-started.md
@@ -144,7 +144,7 @@ eventing resources you need to manage events.
 
 #### Optional Sugar Controller
 
-When installed, the [Sugar Controller for Knative Eventing](TODO:: Link TBD)
+When installed, the [Sugar Controller for Knative Eventing](../install#optional-eventing-extensions)
 will add a controller that reacts to special labels and annotations for your
 resources, you can skip manually creating a Broker in the above step and instead
 label a namespace:
diff --git a/docs/install/any-kubernetes-cluster.md b/docs/install/any-kubernetes-cluster.md
index 46793b24aa8..cb9c0bfec2a 100644
--- a/docs/install/any-kubernetes-cluster.md
+++ b/docs/install/any-kubernetes-cluster.md
@@ -634,15 +634,28 @@ At this point, you have a basic installation of Knative Eventing!
 
    <!-- This indentation is important for things to render properly. -->
    {{< tabs name="eventing_extensions" >}}
-{{% tab name="Enable Broker" %}}
+{{% tab name="Sugar Controller" %}}
 
 <!-- Unclear when this feature came in -->
-{{< feature-state version="v0.5" state="alpha" >}}
+{{< feature-state version="v0.16" state="alpha" >}}
+
+The following command installs the Github Source:
+
+   ```bash
+   kubectl apply --filename {{< artifact repo="eventing" file="eventing-sugar-controller.yaml" >}}
+   ```
+
+The Knative Eventing Sugar Controller will react to special labels and annotations and produce Eventing resources. For example:
+
+ - When a Namespace is labeled with `eventing.knative.dev/injection=enabled`, the controller will create a default broker
+   in that namespace.
+ - When a Trigger is annotated with `eventing.knative.dev/injection=enabled`, the controller will create a Broker named 
+   by that Trigger in the Trigger's Namespace. 
 
 The following command enables the default Broker on a namespace (here `default`):
 
    ```bash
-   kubectl label namespace default knative-eventing-injection=enabled
+   kubectl label namespace default eventing.knative.dev/injection=enabled
    ```
 
 {{< /tab >}}

From bece067fce133dbbb4e55e8e67720d45b4d37a21 Mon Sep 17 00:00:00 2001
From: Scott Nichols <snichols@vmware.com>
Date: Mon, 6 Jul 2020 15:14:14 -0700
Subject: [PATCH 3/3] lint and feedback

---
 docs/eventing/getting-started.md       |  10 +-
 docs/install/any-kubernetes-cluster.md | 605 ++++++++++++++-----------
 2 files changed, 350 insertions(+), 265 deletions(-)

diff --git a/docs/eventing/getting-started.md b/docs/eventing/getting-started.md
index 796575ed87c..fa336686676 100644
--- a/docs/eventing/getting-started.md
+++ b/docs/eventing/getting-started.md
@@ -144,7 +144,8 @@ eventing resources you need to manage events.
 
 #### Optional Sugar Controller
 
-When installed, the [Sugar Controller for Knative Eventing](../install#optional-eventing-extensions)
+When installed, the
+[Sugar Controller for Knative Eventing](../install#optional-eventing-extensions)
 will add a controller that reacts to special labels and annotations for your
 resources, you can skip manually creating a Broker in the above step and instead
 label a namespace:
@@ -369,9 +370,10 @@ events based on the Cloud Event context attributes.
    ```
 
    If the triggers are correctly configured, they will be ready and pointing to
-   the correct **Broker** (the default broker) and **SUBSCRIBER_URI**
-   (triggerName.namespaceName.svc.cluster.local). If this is not the case, see
-   the [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
+   the correct **Broker** (the default broker) and **SUBSCRIBER_URI** has a
+   value similar to (triggerName.namespaceName.svc.cluster.local) _exact value
+   dependent on Broker implementation_. If this is not the case, see the
+   [Debugging Guide](./debugging/README.md) to help troubleshoot the issue.
 
 You have now created all of the resources needed to receive and manage events.
 You created the `Broker`, which manages the events sent to event consumers with
diff --git a/docs/install/any-kubernetes-cluster.md b/docs/install/any-kubernetes-cluster.md
index cb9c0bfec2a..8b9a18770dc 100644
--- a/docs/install/any-kubernetes-cluster.md
+++ b/docs/install/any-kubernetes-cluster.md
@@ -19,26 +19,38 @@ aliases:
   - /docs/install/knative-with-pks
 ---
 
-This guide walks you through the installation of the latest version of
-Knative. Note if you are upgrading an existing installation, follow the
+This guide walks you through the installation of the latest version of Knative.
+Note if you are upgrading an existing installation, follow the
 [instructions here](./upgrade-installation.md).
 
-Knative has two components, which can be installed and used independently or together.
-To help you pick and choose the pieces that are right for you, here is a brief
-description of each:
- - [**Serving**](#installing-the-serving-component) {{< feature-state version="v0.9" state="stable" short=true >}} provides an abstraction for stateless request-based scale-to-zero services.
- - [**Eventing**](#installing-the-eventing-component) {{< feature-state version="v0.16" state="stable" short=true >}} provides abstractions to enable binding event sources (e.g. Github Webhooks, Kafka) and consumers (e.g. Kubernetes or Knative Services).
+Knative has two components, which can be installed and used independently or
+together. To help you pick and choose the pieces that are right for you, here is
+a brief description of each:
 
-Knative also has an [**Observability plugin**](#installing-the-observability-plugin) {{< feature-state version="v0.14" state="deprecated" short=true >}}  which provides standard tooling that can be used to get visibility into the health of the software running on Knative.
+- [**Serving**](#installing-the-serving-component)
+  {{< feature-state version="v0.9" state="stable" short=true >}} provides an
+  abstraction for stateless request-based scale-to-zero services.
+- [**Eventing**](#installing-the-eventing-component)
+  {{< feature-state version="v0.16" state="stable" short=true >}} provides
+  abstractions to enable binding event sources (e.g. Github Webhooks, Kafka) and
+  consumers (e.g. Kubernetes or Knative Services).
+
+Knative also has an
+[**Observability plugin**](#installing-the-observability-plugin)
+{{< feature-state version="v0.14" state="deprecated" short=true >}} which
+provides standard tooling that can be used to get visibility into the health of
+the software running on Knative.
 
 ## Before you begin
 
-This guide assumes that you want to install an upstream Knative release on a Kubernetes cluster. A growing number of vendors have managed Knative offerings; see the [Knative Offerings](../knative-offerings.md) page for a full list.
+This guide assumes that you want to install an upstream Knative release on a
+Kubernetes cluster. A growing number of vendors have managed Knative offerings;
+see the [Knative Offerings](../knative-offerings.md) page for a full list.
 
-Knative {{< version >}} requires a Kubernetes cluster v1.15 or newer, as well as a compatible
-`kubectl`. This guide assumes that you've already created a Kubernetes cluster,
-and that you are using bash in a Mac or Linux environment; some commands will
-need to be adjusted for use in a Windows environment.
+Knative {{< version >}} requires a Kubernetes cluster v1.15 or newer, as well as
+a compatible `kubectl`. This guide assumes that you've already created a
+Kubernetes cluster, and that you are using bash in a Mac or Linux environment;
+some commands will need to be adjusted for use in a Windows environment.
 
 <!-- TODO: Link to provisioning guide for advanced installation -->
 
@@ -46,10 +58,11 @@ need to be adjusted for use in a Windows environment.
 
 {{< feature-state version="v0.9" state="stable" >}}
 
-
 The following commands install the Knative Serving component.
 
-1. Install the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (aka CRDs):
+1. Install the
+   [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   (aka CRDs):
 
    ```bash
    kubectl apply --filename {{< artifact repo="serving" file="serving-crds.yaml" >}}
@@ -62,11 +75,13 @@ The following commands install the Knative Serving component.
    ```
 
 1. Pick a networking layer (alphabetical):
-   <!-- TODO: Link to document/diagram describing what is a networking layer.  -->
 
-   <!-- This indentation is important for things to render properly. -->
+      <!-- TODO: Link to document/diagram describing what is a networking layer.  -->
+
+      <!-- This indentation is important for things to render properly. -->
+
    {{< tabs name="serving_networking" default="Istio" >}}
-{{% tab name="Ambassador" %}}
+   {{% tab name="Ambassador" %}}
 
 {{% feature-state version="v0.8" state="alpha" %}}
 
@@ -100,12 +115,12 @@ The following commands install Ambassador and enable its Knative integration.
 
 1. To configure Knative Serving to use Ambassador by default:
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"ingress.class":"ambassador.ingress.networking.knative.dev"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"ingress.class":"ambassador.ingress.networking.knative.dev"}}'
+   ```
 
 1. Fetch the External IP or CNAME:
 
@@ -139,12 +154,12 @@ The following commands install Contour and enable its Knative integration.
 
 1. To configure Knative Serving to use Contour by default:
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"ingress.class":"contour.ingress.networking.knative.dev"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"ingress.class":"contour.ingress.networking.knative.dev"}}'
+   ```
 
 1. Fetch the External IP or CNAME:
 
@@ -160,7 +175,9 @@ The following commands install Contour and enable its Knative integration.
 
 {{% feature-state version="v0.8" state="alpha" %}}
 
-_For a detailed guide on Gloo integration, see [Installing Gloo for Knative](https://docs.solo.io/gloo/latest/installation/knative/) in the Gloo documentation._
+_For a detailed guide on Gloo integration, see
+[Installing Gloo for Knative](https://docs.solo.io/gloo/latest/installation/knative/)
+in the Gloo documentation._
 
 The following commands install Gloo and enable its Knative integration.
 
@@ -177,13 +194,14 @@ The following commands install Gloo and enable its Knative integration.
    export PATH=$HOME/.gloo/bin:$PATH
    ```
 
-   Or following the [Gloo CLI install instructions](https://docs.solo.io/gloo/latest/installation/knative/#install-command-line-tool-cli).
+   Or following the
+   [Gloo CLI install instructions](https://docs.solo.io/gloo/latest/installation/knative/#install-command-line-tool-cli).
 
 1. Install Gloo and the Knative integration:
 
-    ```bash
-    glooctl install knative --install-knative=false
-    ```
+   ```bash
+   glooctl install knative --install-knative=false
+   ```
 
 1. Fetch the External IP or CNAME:
 
@@ -235,12 +253,12 @@ The following commands install Kong and enable its Knative integration.
 
 1. To configure Knative Serving to use Kong by default:
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"ingress.class":"kong"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"ingress.class":"kong"}}'
+   ```
 
 1. Fetch the External IP or CNAME:
 
@@ -266,12 +284,12 @@ The following commands install Kourier and enable its Knative integration.
 
 1. To configure Knative Serving to use Kourier by default:
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"ingress.class":"kourier.ingress.networking.knative.dev"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"ingress.class":"kourier.ingress.networking.knative.dev"}}'
+   ```
 
 1. Fetch the External IP or CNAME:
 
@@ -281,40 +299,44 @@ The following commands install Kourier and enable its Knative integration.
 
    Save this for configuring DNS below.
 
-{{< /tab >}}
-{{< /tabs >}}
+{{< /tab >}} {{< /tabs >}}
 
 1. Configure DNS
 
-   <!-- This indentation is important for things to render properly. -->
-   {{< tabs name="serving_dns" >}}
-{{% tab name="Magic DNS (xip.io)" %}}
-We ship a simple Kubernetes Job called "default domain" that will (see caveats) configure Knative Serving to use <a href="http://xip.io">xip.io</a> as the default DNS suffix.
+      <!-- This indentation is important for things to render properly. -->
+
+   {{< tabs name="serving_dns" >}} {{% tab name="Magic DNS (xip.io)" %}} We ship
+   a simple Kubernetes Job called "default domain" that will (see caveats)
+   configure Knative Serving to use <a href="http://xip.io">xip.io</a> as the
+   default DNS suffix.
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="serving-default-domain.yaml" >}}
 ```
 
-**Caveat**: This will only work if the cluster LoadBalancer service exposes an IPv4 address or hostname, so it will not work with IPv6 clusters or local setups like Minikube.  For these, see "Real DNS" or "Temporary DNS".
-{{< /tab >}}
-
+**Caveat**: This will only work if the cluster LoadBalancer service exposes an
+IPv4 address or hostname, so it will not work with IPv6 clusters or local setups
+like Minikube. For these, see "Real DNS" or "Temporary DNS". {{< /tab >}}
 
-{{% tab name="Real DNS" %}}
-To configure DNS for Knative, take the External IP or CNAME from setting up networking, and configure it with your DNS provider as follows:
+{{% tab name="Real DNS" %}} To configure DNS for Knative, take the External IP
+or CNAME from setting up networking, and configure it with your DNS provider as
+follows:
 
-- If the networking layer produced an External IP address, then configure a wildcard `A` record for the domain:
+- If the networking layer produced an External IP address, then configure a
+  wildcard `A` record for the domain:
 
-    ```
-    # Here knative.example.com is the domain suffix for your cluster
-    *.knative.example.com == A 35.233.41.212
-    ```
+  ```
+  # Here knative.example.com is the domain suffix for your cluster
+  *.knative.example.com == A 35.233.41.212
+  ```
 
-- If the networking layer produced a CNAME, then configure a CNAME record for the domain:
+- If the networking layer produced a CNAME, then configure a CNAME record for
+  the domain:
 
-    ```
-    # Here knative.example.com is the domain suffix for your cluster
-    *.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com
-    ```
+  ```
+  # Here knative.example.com is the domain suffix for your cluster
+  *.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com
+  ```
 
 Once your DNS provider has been configured, direct Knative to use that domain:
 
@@ -328,31 +350,41 @@ kubectl patch configmap/config-domain \
 
 {{< /tab >}}
 
-{{% tab name="Temporary DNS" %}}
-If you are using `curl` to access the sample applications, or your own Knative app, and are unable to use the "Magic DNS (xip.io)" or "Real DNS" methods, there is a temporary approach. This is useful for those who wish to evaluate Knative without altering their DNS configuration, as per the "Real DNS" method, or cannot use the "Magic DNS" method due to using, for example, minikube locally or IPv6 clusters.
+{{% tab name="Temporary DNS" %}} If you are using `curl` to access the sample
+applications, or your own Knative app, and are unable to use the "Magic DNS
+(xip.io)" or "Real DNS" methods, there is a temporary approach. This is useful
+for those who wish to evaluate Knative without altering their DNS configuration,
+as per the "Real DNS" method, or cannot use the "Magic DNS" method due to using,
+for example, minikube locally or IPv6 clusters.
 
 To access your application using `curl` using this method:
 
 1. After starting your application, get the URL of your application:
 
-    ```bash
-    kubectl get ksvc
-    ```
+   ```bash
+   kubectl get ksvc
+   ```
 
    The output should be similar to:
 
    ```bash
    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
-   helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True    
+   helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True
    ```
 
-1. Instruct `curl` to connect to the External IP or CNAME defined by the networking layer in section 3 above, and use the `-H "Host:"` command-line option to specify the Knative application's host name. For example, if the networking layer defines your External IP and port to be `http://192.168.39.228:32198` and you wish to access the above `helloworld-go` application, use:
+1. Instruct `curl` to connect to the External IP or CNAME defined by the
+   networking layer in section 3 above, and use the `-H "Host:"` command-line
+   option to specify the Knative application's host name. For example, if the
+   networking layer defines your External IP and port to be
+   `http://192.168.39.228:32198` and you wish to access the above
+   `helloworld-go` application, use:
 
    ```bash
    curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
    ```
 
-   In the case of the provided `helloworld-go` sample application, the output should, using the default configuration, be:
+   In the case of the provided `helloworld-go` sample application, the output
+   should, using the default configuration, be:
 
    ```
    Hello Go Sample v1!
@@ -364,7 +396,8 @@ Refer to the "Real DNS" method for a permanent solution.
 
 {{< /tabs >}}
 
-1. Monitor the Knative components until all of the components show a `STATUS` of `Running` or `Completed`:
+1. Monitor the Knative components until all of the components show a `STATUS` of
+   `Running` or `Completed`:
 
    ```bash
    kubectl get pods --namespace knative-serving
@@ -372,16 +405,14 @@ Refer to the "Real DNS" method for a permanent solution.
 
 At this point, you have a basic installation of Knative Serving!
 
-
 ### Optional Serving extensions
 
-{{< tabs name="serving_extensions" >}}
-{{% tab name="HPA autoscaling" %}}
+{{< tabs name="serving_extensions" >}} {{% tab name="HPA autoscaling" %}}
 
 {{% feature-state version="v0.8" state="beta" %}}
 
 Knative also supports the use of the Kubernetes Horizontal Pod Autoscaler (HPA)
-for driving autoscaling decisions.  The following command will install the
+for driving autoscaling decisions. The following command will install the
 components needed to support HPA-class autoscaling:
 
 ```bash
@@ -396,48 +427,55 @@ kubectl apply --filename {{< artifact repo="serving" file="serving-hpa.yaml" >}}
 
 {{% feature-state version="v0.6" state="alpha" %}}
 
-Knative supports automatically provisioning TLS certificates via [cert-manager](https://cert-manager.io/docs/).  The following commands will install the components needed to support the provisioning of TLS certificates via cert-manager.
+Knative supports automatically provisioning TLS certificates via
+[cert-manager](https://cert-manager.io/docs/). The following commands will
+install the components needed to support the provisioning of TLS certificates
+via cert-manager.
 
-1. First, install [cert-manager version `0.12.0` or higher](../serving/installing-cert-manager.md)
+1. First, install
+   [cert-manager version `0.12.0` or higher](../serving/installing-cert-manager.md)
 
 2. Next, install the component that integrates Knative with cert-manager:
 
-    ```bash
-    kubectl apply --filename {{< artifact repo="net-certmanager" file="release.yaml" >}}
-    ```
+   ```bash
+   kubectl apply --filename {{< artifact repo="net-certmanager" file="release.yaml" >}}
+   ```
 
-3. Now configure Knative to [automatically configure TLS certificates](../serving/using-auto-tls.md).
-{{< /tab >}}
+3. Now configure Knative to
+   [automatically configure TLS certificates](../serving/using-auto-tls.md).
+   {{< /tab >}}
 
 {{% tab name="TLS via HTTP01" %}}
 
 {{% feature-state version="v0.14" state="alpha" %}}
 
-Knative supports automatically provisioning TLS certificates using Let's Encrypt HTTP01 challenges.  The following commands will install the components needed to support that.
+Knative supports automatically provisioning TLS certificates using Let's Encrypt
+HTTP01 challenges. The following commands will install the components needed to
+support that.
 
 1. First, install the `net-http01` controller:
 
-    ```bash
-    kubectl apply --filename {{< artifact repo="net-http01" file="release.yaml" >}}
-    ```
+   ```bash
+   kubectl apply --filename {{< artifact repo="net-http01" file="release.yaml" >}}
+   ```
 
 2. Next, configure the `certificate.class` to use this certificate type.
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"certificate.class":"net-http01.certificate.networking.knative.dev"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"certificate.class":"net-http01.certificate.networking.knative.dev"}}'
+   ```
 
 3. Lastly, enable auto-TLS.
 
-    ```bash
-    kubectl patch configmap/config-network \
-      --namespace knative-serving \
-      --type merge \
-      --patch '{"data":{"autoTLS":"Enabled"}}'
-    ```
+   ```bash
+   kubectl patch configmap/config-network \
+     --namespace knative-serving \
+     --type merge \
+     --patch '{"data":{"autoTLS":"Enabled"}}'
+   ```
 
 {{< /tab >}}
 
@@ -445,31 +483,37 @@ Knative supports automatically provisioning TLS certificates using Let's Encrypt
 
 {{% feature-state version="v0.12" state="alpha" %}}
 
-If you are using a Certificate implementation that supports provisioning wildcard certificates (e.g. cert-manager with a DNS01 issuer), then the most efficient way to provision certificates is with the namespace wildcard certificate controller.  The following command will install the components needed to provision wildcard certificates in each namespace:
+If you are using a Certificate implementation that supports provisioning
+wildcard certificates (e.g. cert-manager with a DNS01 issuer), then the most
+efficient way to provision certificates is with the namespace wildcard
+certificate controller. The following command will install the components needed
+to provision wildcard certificates in each namespace:
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="serving-nscert.yaml" >}}
 ```
 
-> Note this will not work with HTTP01 either via cert-manager or the net-http01 options.
-
-{{< /tab >}}
-{{< /tabs >}}
+> Note this will not work with HTTP01 either via cert-manager or the net-http01
+> options.
 
+{{< /tab >}} {{< /tabs >}}
 
 ### Getting started with Serving
 
-Deploy your first app with the [getting started with Knative app deployment](../serving/getting-started-knative-app.md) guide.  You can also find a number of samples for Knative Serving [here](../serving/samples/).
-
+Deploy your first app with the
+[getting started with Knative app deployment](../serving/getting-started-knative-app.md)
+guide. You can also find a number of samples for Knative Serving
+[here](../serving/samples/).
 
 ## Installing the Eventing component
 
 {{< feature-state version="v0.16" state="stable" >}}
 
-
 The following commands install the Knative Eventing component.
 
-1. Install the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (aka CRDs):
+1. Install the
+   [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+   (aka CRDs):
 
    ```bash
    kubectl apply --filename {{< artifact repo="eventing" file="eventing-crds.yaml" >}}
@@ -481,13 +525,22 @@ The following commands install the Knative Eventing component.
    kubectl apply --filename {{< artifact repo="eventing" file="eventing-core.yaml" >}}
    ```
 
+   _Note_: If your Kubernetes cluster comes with pre-installed Istio, make sure
+   it has `cluster-local-gateway`
+   [deployed](https://github.com/knative/serving/blob/master/DEVELOPMENT.md#deploy-istio).
+   Depending on which Istio version you have, you'd need to apply the
+   `istio-knative-extras.yaml` in the corresponding version folder at
+   [here](https://github.com/knative/serving/tree/{{< branch >}}/third_party).
+
 1. Install a default Channel (messaging) layer (alphabetical).
 
-   <!-- This indentation is important for things to render properly. -->
+      <!-- This indentation is important for things to render properly. -->
+
    {{< tabs name="eventing_channels" default="In-Memory (standalone)" >}}
-{{% tab name="Apache Kafka Channel" %}}
+   {{% tab name="Apache Kafka Channel" %}}
 
-1. First, [Install Apache Kafka for Kubernetes](../eventing/samples/kafka/README.md)
+1. First,
+   [Install Apache Kafka for Kubernetes](../eventing/samples/kafka/README.md)
 
 1. Then install the Apache Kafka Channel:
 
@@ -497,7 +550,8 @@ The following commands install the Knative Eventing component.
     | kubectl apply --filename -
    ```
 
-To learn more about the Apache Kafka channel, try [our sample](../eventing/samples/kafka/channel/README.md)
+To learn more about the Apache Kafka channel, try
+[our sample](../eventing/samples/kafka/channel/README.md)
 
 {{< /tab >}}
 
@@ -510,7 +564,8 @@ To learn more about the Apache Kafka channel, try [our sample](../eventing/sampl
    kubectl apply --filename {{< artifact org="google" repo="knative-gcp" file="cloud-run-events.yaml" >}}
    ```
 
-To learn more about the Google Cloud Pub/Sub Channel, try [our sample](https://github.com/google/knative-gcp/blob/master/docs/examples/channel/README.md)
+To learn more about the Google Cloud Pub/Sub Channel, try
+[our sample](https://github.com/google/knative-gcp/blob/master/docs/examples/channel/README.md)
 
 {{< /tab >}}
 
@@ -518,17 +573,21 @@ To learn more about the Google Cloud Pub/Sub Channel, try [our sample](https://g
 
 {{< feature-state version="v0.16" state="stable" >}}
 
-The following command installs an implementation of Channel that runs in-memory.  This implementation is nice because it is simple and standalone, but it is unsuitable for production use cases.
+The following command installs an implementation of Channel that runs in-memory.
+This implementation is nice because it is simple and standalone, but it is
+unsuitable for production use cases.
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing" file="in-memory-channel.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing" file="in-memory-channel.yaml" >}}
+```
 
 {{< /tab >}}
 
 {{% tab name="NATS Channel" %}}
 
-1. First, [Install NATS Streaming for Kubernetes](https://github.com/knative/eventing-contrib/blob/{{< version >}}/natss/config/broker/README.md)
+1. First, [Install NATS Streaming for
+   Kubernetes](https://github.com/knative/eventing-contrib/blob/{{<
+   version >}}/natss/config/broker/README.md)
 
 1. Then install the NATS Streaming Channel:
 
@@ -544,77 +603,81 @@ The following command installs an implementation of Channel that runs in-memory.
 
 1. Install a Broker (eventing) layer:
 
-   <!-- This indentation is important for things to render properly. -->
+      <!-- This indentation is important for things to render properly. -->
+
    {{< tabs name="eventing_brokers" default="MT-Channel-based" >}}
-{{% tab name="MT-Channel-based" %}}
-{{< feature-state version="v0.16" state="stable" >}}
+   {{% tab name="MT-Channel-based" %}}
+   {{< feature-state version="v0.16" state="stable" >}}
 
-The following command installs an implementation of Broker that utilizes Channels
-and runs event routing components in a System Namespace, providing a smaller and
-simpler installation.
+The following command installs an implementation of Broker that utilizes
+Channels and runs event routing components in a System Namespace, providing a
+smaller and simpler installation.
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing" file="mt-channel-broker.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing" file="mt-channel-broker.yaml" >}}
+```
 
 To customize which broker channel implementation is used, update the following
 ConfigMap to specify which configurations are used for which namespaces:
 
-   ```yaml
-   apiVersion: v1
-   kind: ConfigMap
-   metadata:
-     name: config-br-defaults
-     namespace: knative-eventing
-   data:
-     default-br-config: |
-       # This is the cluster-wide default broker channel.
-       clusterDefault:
-         brokerClass: MTChannelBasedBroker
-         apiVersion: v1
-         kind: ConfigMap
-         name: imc-channel
-         namespace: knative-eventing
-       # This allows you to specify different defaults per-namespace,
-       # in this case the "some-namespace" namespace will use the Kafka
-       # channel ConfigMap by default (only for example, you will need
-       # to install kafka also to make use of this).
-       namespaceDefaults:
-         some-namespace:
-           brokerClass: MTChannelBasedBroker
-           apiVersion: v1
-           kind: ConfigMap
-           name: kafka-channel
-           namespace: knative-eventing
-   ```
-
-The referenced `imc-channel` and `kafka-channel` example ConfigMaps would look like:
-   ```yaml
-   apiVersion: v1
-   kind: ConfigMap
-   metadata:
-     name: imc-channel
-     namespace: knative-eventing
-   data:
-     channelTemplateSpec: |
-       apiVersion: messaging.knative.dev/v1beta1
-       kind: InMemoryChannel
-   ---
-   apiVersion: v1
-   kind: ConfigMap
-   metadata:
-     name: kafka-channel
-     namespace: knative-eventing
-   data:
-     channelTemplateSpec: |
-       apiVersion: messaging.knative.dev/v1alpha1
-       kind: KafkaChannel
-       spec:
-         numPartitions: 3
-         replicationFactor: 1
-   ```
-
-_In order to use the KafkaChannel make sure it is installed on the cluster as discussed above._
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: config-br-defaults
+  namespace: knative-eventing
+data:
+  default-br-config: |
+    # This is the cluster-wide default broker channel.
+    clusterDefault:
+      brokerClass: MTChannelBasedBroker
+      apiVersion: v1
+      kind: ConfigMap
+      name: imc-channel
+      namespace: knative-eventing
+    # This allows you to specify different defaults per-namespace,
+    # in this case the "some-namespace" namespace will use the Kafka
+    # channel ConfigMap by default (only for example, you will need
+    # to install kafka also to make use of this).
+    namespaceDefaults:
+      some-namespace:
+        brokerClass: MTChannelBasedBroker
+        apiVersion: v1
+        kind: ConfigMap
+        name: kafka-channel
+        namespace: knative-eventing
+```
+
+The referenced `imc-channel` and `kafka-channel` example ConfigMaps would look
+like:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: imc-channel
+  namespace: knative-eventing
+data:
+  channelTemplateSpec: |
+    apiVersion: messaging.knative.dev/v1beta1
+    kind: InMemoryChannel
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: kafka-channel
+  namespace: knative-eventing
+data:
+  channelTemplateSpec: |
+    apiVersion: messaging.knative.dev/v1alpha1
+    kind: KafkaChannel
+    spec:
+      numPartitions: 3
+      replicationFactor: 1
+```
+
+_In order to use the KafkaChannel make sure it is installed on the cluster as
+discussed above._
 
 {{< /tab >}}
 
@@ -629,34 +692,37 @@ _In order to use the KafkaChannel make sure it is installed on the cluster as di
 
 At this point, you have a basic installation of Knative Eventing!
 
-
 ### Optional Eventing extensions
 
    <!-- This indentation is important for things to render properly. -->
-   {{< tabs name="eventing_extensions" >}}
-{{% tab name="Sugar Controller" %}}
+
+{{< tabs name="eventing_extensions" >}} {{% tab name="Sugar Controller" %}}
 
 <!-- Unclear when this feature came in -->
+
 {{< feature-state version="v0.16" state="alpha" >}}
 
-The following command installs the Github Source:
+The following command installs the Eventing Sugar Controller:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing" file="eventing-sugar-controller.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing" file="eventing-sugar-controller.yaml" >}}
+```
 
-The Knative Eventing Sugar Controller will react to special labels and annotations and produce Eventing resources. For example:
+The Knative Eventing Sugar Controller will react to special labels and
+annotations and produce Eventing resources. For example:
 
- - When a Namespace is labeled with `eventing.knative.dev/injection=enabled`, the controller will create a default broker
-   in that namespace.
- - When a Trigger is annotated with `eventing.knative.dev/injection=enabled`, the controller will create a Broker named 
-   by that Trigger in the Trigger's Namespace. 
+- When a Namespace is labeled with `eventing.knative.dev/injection=enabled`, the
+  controller will create a default broker in that namespace.
+- When a Trigger is annotated with `eventing.knative.dev/injection=enabled`, the
+  controller will create a Broker named by that Trigger in the Trigger's
+  Namespace.
 
-The following command enables the default Broker on a namespace (here `default`):
+The following command enables the default Broker on a namespace (here
+`default`):
 
-   ```bash
-   kubectl label namespace default eventing.knative.dev/injection=enabled
-   ```
+```bash
+kubectl label namespace default eventing.knative.dev/injection=enabled
+```
 
 {{< /tab >}}
 
@@ -666,11 +732,12 @@ The following command enables the default Broker on a namespace (here `default`)
 
 The following command installs the Github Source:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing-contrib" file="github.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing-contrib" file="github.yaml" >}}
+```
 
-To learn more about the Github source, try [our sample](../eventing/samples/github-source/README.md)
+To learn more about the Github source, try
+[our sample](../eventing/samples/github-source/README.md)
 
 {{< /tab >}}
 
@@ -679,11 +746,12 @@ To learn more about the Github source, try [our sample](../eventing/samples/gith
 
 The following command installs the Apache Camel-K Source:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing-contrib" file="camel.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing-contrib" file="camel.yaml" >}}
+```
 
-To learn more about the Apache Camel-K source, try [our sample](../eventing/samples/apache-camel-source/README.md)
+To learn more about the Apache Camel-K source, try
+[our sample](../eventing/samples/apache-camel-source/README.md)
 
 {{< /tab >}}
 
@@ -693,11 +761,12 @@ To learn more about the Apache Camel-K source, try [our sample](../eventing/samp
 
 The following command installs the Apache Kafka Source:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing-contrib" file="kafka-source.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing-contrib" file="kafka-source.yaml" >}}
+```
 
-To learn more about the Apache Kafka source, try [our sample](../eventing/samples/kafka/source/README.md)
+To learn more about the Apache Kafka source, try
+[our sample](../eventing/samples/kafka/source/README.md)
 
 {{< /tab >}}
 
@@ -707,18 +776,22 @@ To learn more about the Apache Kafka source, try [our sample](../eventing/sample
 
 The following command installs the GCP Sources:
 
-   ```bash
-   # This installs both the Sources and the Channel.
-   kubectl apply --filename {{< artifact org="google" repo="knative-gcp" file="cloud-run-events.yaml" >}}
-   ```
+```bash
+# This installs both the Sources and the Channel.
+kubectl apply --filename {{< artifact org="google" repo="knative-gcp" file="cloud-run-events.yaml" >}}
+```
 
-To learn more about the Cloud Pub/Sub source, try [our sample](../eventing/samples/cloud-pubsub-source/README.md).
+To learn more about the Cloud Pub/Sub source, try
+[our sample](../eventing/samples/cloud-pubsub-source/README.md).
 
-To learn more about the Cloud Storage source, try [our sample](../eventing/samples/cloud-storage-source/README.md).
+To learn more about the Cloud Storage source, try
+[our sample](../eventing/samples/cloud-storage-source/README.md).
 
-To learn more about the Cloud Scheduler source, try [our sample](../eventing/samples/cloud-scheduler-source/README.md).
+To learn more about the Cloud Scheduler source, try
+[our sample](../eventing/samples/cloud-scheduler-source/README.md).
 
-To learn more about the Cloud Audit Logs source, try [our sample](../eventing/samples/cloud-audit-logs-source/README.md).
+To learn more about the Cloud Audit Logs source, try
+[our sample](../eventing/samples/cloud-audit-logs-source/README.md).
 
 {{< /tab >}}
 
@@ -728,11 +801,13 @@ To learn more about the Cloud Audit Logs source, try [our sample](../eventing/sa
 
 The following command installs the Apache CouchDB Source:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="eventing-contrib" file="couchdb.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact repo="eventing-contrib" file="couchdb.yaml" >}}
+```
 
-To learn more about the Apache CouchDB source, read [our documentation]((https://github.com/knative/eventing-contrib/blob/{{< version >}}/couchdb/README.md)
+To learn more about the Apache CouchDB source, read [our
+documentation]((https://github.com/knative/eventing-contrib/blob/{{<
+version >}}/couchdb/README.md)
 
 {{< /tab >}}
 
@@ -742,15 +817,15 @@ To learn more about the Apache CouchDB source, read [our documentation]((https:/
 
 The following command installs the VMware Sources and Bindings:
 
-   ```bash
-   kubectl apply --filename {{< artifact org="vmware-tanzu" repo="sources-for-knative" file="release.yaml" >}}
-   ```
+```bash
+kubectl apply --filename {{< artifact org="vmware-tanzu" repo="sources-for-knative" file="release.yaml" >}}
+```
 
-To learn more about the VMware sources and bindings, try [our samples](https://github.com/vmware-tanzu/sources-for-knative/tree/master/samples/README.md).
+To learn more about the VMware sources and bindings, try
+[our samples](https://github.com/vmware-tanzu/sources-for-knative/tree/master/samples/README.md).
 
 {{< /tab >}}
 
-
 <!-- TODO: prometheus source -->
 <!-- TODO: AWS SQS source  -->
 
@@ -758,17 +833,18 @@ To learn more about the VMware sources and bindings, try [our samples](https://g
 
 {{< /tabs >}}
 
-
 ### Getting started with Eventing
 
-You can find a number of samples for Knative Eventing [here](../eventing/samples/README.md). A quick-start guide is available [here](../eventing/getting-started.md).
-
+You can find a number of samples for Knative Eventing
+[here](../eventing/samples/README.md). A quick-start guide is available
+[here](../eventing/getting-started.md).
 
 ## Installing the Observability plugin
 
 {{< feature-state version="v0.14" state="deprecated" >}}
 
-Install the following observability features to enable logging, metrics, and request tracing in your Serving and Eventing components.
+Install the following observability features to enable logging, metrics, and
+request tracing in your Serving and Eventing components.
 
 All observibility plugins require that you first install the core:
 
@@ -776,58 +852,65 @@ All observibility plugins require that you first install the core:
 kubectl apply --filename {{< artifact repo="serving" file="monitoring-core.yaml" >}}
 ```
 
-After the core is installed, you can choose to install one or all of the following observability plugins:
+After the core is installed, you can choose to install one or all of the
+following observability plugins:
 
-- Install [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/) for metrics:
+- Install [Prometheus](https://prometheus.io/) and
+  [Grafana](https://grafana.com/) for metrics:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="serving" file="monitoring-metrics-prometheus.yaml" >}}
-   ```
+  ```bash
+  kubectl apply --filename {{< artifact repo="serving" file="monitoring-metrics-prometheus.yaml" >}}
+  ```
 
-- Install the [ELK stack](https://www.elastic.co/what-is/elk-stack) (Elasticsearch, Logstash and Kibana) for logs:
+- Install the [ELK stack](https://www.elastic.co/what-is/elk-stack)
+  (Elasticsearch, Logstash and Kibana) for logs:
 
-   ```bash
-   kubectl apply --filename {{< artifact repo="serving" file="monitoring-logs-elasticsearch.yaml" >}}
-   ```
+  ```bash
+  kubectl apply --filename {{< artifact repo="serving" file="monitoring-logs-elasticsearch.yaml" >}}
+  ```
 
 - Install [Jaeger](https://jaegertracing.io/) for distributed tracing
 
-   <!-- This indentation is important for things to render properly. -->
-   {{< tabs name="jaeger" default="In-Memory (standalone)" >}}
-{{% tab name="In-Memory (standalone)" %}}
-To install the in-memory (standalone) version of Jaeger, run the following command:
+     <!-- This indentation is important for things to render properly. -->
+
+  {{< tabs name="jaeger" default="In-Memory (standalone)" >}}
+  {{% tab name="In-Memory (standalone)" %}} To install the in-memory
+  (standalone) version of Jaeger, run the following command:
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="monitoring-tracing-jaeger-in-mem.yaml" >}}
 ```
+
 {{< /tab >}}
 
-{{% tab name="ELK stack" %}}
-To install the ELK version of Jaeger (needs the ELK install above), run the following command:
+{{% tab name="ELK stack" %}} To install the ELK version of Jaeger (needs the ELK
+install above), run the following command:
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="monitoring-tracing-jaeger.yaml" >}}
 ```
-{{< /tab >}}
-{{< /tabs >}}
+
+{{< /tab >}} {{< /tabs >}}
 
 - Install [Zipkin](https://zipkin.io/) for distributed tracing
 
-   <!-- This indentation is important for things to render properly. -->
-   {{< tabs name="zipkin" default="In-Memory (standalone)" >}}
-{{% tab name="In-Memory (standalone)" %}}
-To install the in-memory (standalone) version of Zipkin, run the following command:
+     <!-- This indentation is important for things to render properly. -->
+
+  {{< tabs name="zipkin" default="In-Memory (standalone)" >}}
+  {{% tab name="In-Memory (standalone)" %}} To install the in-memory
+  (standalone) version of Zipkin, run the following command:
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="monitoring-tracing-zipkin-in-mem.yaml" >}}
 ```
+
 {{< /tab >}}
 
-{{% tab name="ELK stack" %}}
-To install the ELK version of Zipkin (needs the ELK install above), run the following command:
+{{% tab name="ELK stack" %}} To install the ELK version of Zipkin (needs the ELK
+install above), run the following command:
 
 ```bash
 kubectl apply --filename {{< artifact repo="serving" file="monitoring-tracing-zipkin.yaml" >}}
 ```
-{{< /tab >}}
-{{< /tabs >}}
+
+{{< /tab >}} {{< /tabs >}}