Misc fixes for the Knative tutorial too small to warrant their own issues

Author: syedriko

01-basics/.editorconfig

@@ -4,7 +4,6 @@
 ** xref:01-setup.adoc#kubernetes-cluster[Kubernetes Cluster]
 *** xref:01-setup.adoc#install-knative-minikube[Install with Minikube ]
 **** xref:01-setup.adoc#start-minikube[Configure and Start minikube ]
-**** xref:01-setup.adoc[Install Knative ]
 **** xref:01-setup.adoc#install-knative-istio[Install Istio ]
 **** xref:01-setup.adoc#install-knative-serving[Install Knative Serving ]
 **** xref:01-setup.adoc#install-knative-build[Install Knative Build]
@@ -44,7 +43,7 @@
 ** xref:04-scaling.adoc#scaling-invoke-service[Invoke Service]
 ** xref:04-scaling.adoc#scaling-scale-to-zero[Scale to Zero]
 *** xref:04-scaling.adoc#scaling-observer-scale-to-zero[Observing default scale down ]
-*** xref:04-scaling.adoc#scaling-observer-scale-to-zero-1m[Change scale to zero time]
+*** xref:04-scaling.adoc#scaling-observer-scale-to-zero-1m[Change scale-to-zero time]
 *** xref:04-scaling.adoc#scaling-reset-to-defaults[Reset to Defaults]
 ** xref:04-scaling.adoc#scaling-auto-scaling[Auto Scaling]
 *** xref:04-scaling.adoc#scaling-autoscaling-deploy-service[Deploy Service]

documentation/modules/ROOT/nav.adoc

@@ -9,17 +9,22 @@ The following CLI tools are required for running the exercises in this tutorial.
 [cols="4*^,4*."]
 |===
 |**Tool** |**macOS** |**Fedora** | **Remarks**
-| `minikube` 
+| `minikube`
 | https://kubernetes.io/docs/setup/minikube
 | https://kubernetes.io/docs/setup/minikube
 |
 
-| `minishift` 
+| `minishift`
 | https://github.com/minishift/minishift/releases
 | https://github.com/minishift/minishift/releases
 |
 
-| https://maven.apacge.org[Apache Maven]
+| `git`
+| https://git-scm.com/download/mac
+| `dnf install git`
+|
+
+| https://maven.apache.org[Apache Maven]
 | `brew install maven`
 | `dnf install maven`
 |
@@ -41,12 +46,12 @@ The following CLI tools are required for running the exercises in this tutorial.
 
 | https://github.com/JoeDog/siege[siege]
 | `brew install siege`
-| https://github.com/JoeDog/siege  
+| `dnf install siege`
 |
 
 | watch
-|`brew install watch`
-| it will be pre-installed
+| `brew install watch`
+| `dnf install procps-ng`
 |
 
 | kubectx and kubens
@@ -57,14 +62,14 @@ The following CLI tools are required for running the exercises in this tutorial.
 
 [#download-tutorial-sources]
 == Download Tutorial Sources
-Before we start to setting up the environment, lets clone the tutorial sources and call the cloned folder as `$TUTORIAL_HOME`
+Before we start setting up the environment, let's clone the tutorial sources and set the `TUTORIAL_HOME` environment variable to point to the root directory of the tutorial:
 
 [source,bash]
 ----
 git clone https://github.com/redhat-developer-demos/knative-tutorial
 ----
 
-The `work` folder in `$TUTORIAL_HOME` can be used to download the demo application resources and refer them during the exercises. The `work` folder has a README, which has instructions on source code repo and git commands to clone the sources.
+The `work` folder in `$TUTORIAL_HOME` can be used to download the demo application resources and refer to them during the exercises. The `work` folder has a README with instructions on the source code repo and git commands to clone the sources.
 
 [IMPORTANT,subs="+macros,+attributes"]
 ====
@@ -86,4 +91,4 @@ include::partial$openshift-setup.adoc[]
 [#setup-work-folder]
 == Work folder
 
-The work folder i.e `$TUTORIAL_HOME/work` can be used as a work directory during the build. The README in the work folder as the GitHub repository links of the applications `greeter` and `event-greeter` that will be used in various exercises.
+The work folder i.e `$TUTORIAL_HOME/work` can be used as a work directory during the build. The README in the work folder has the GitHub repository links of the applications `greeter` and `event-greeter` that will be used in various exercises.

documentation/modules/ROOT/pages/01-setup.adoc

@@ -88,7 +88,7 @@ NOTE: Sometimes the response might not be returned immediately especially when t
 [#basics-see-what-you-have-deployed]
 == See what you have deployed
 
-The service based deployment strategy that we did now will create many knative resources, the following commands will help you to query and find what has been deployed.
+The service-based deployment strategy that we did now will create many Knative resources, the following commands will help you to query and find what has been deployed.
 
 [#basics-show-knative-services]
 === service 

documentation/modules/ROOT/pages/02-basic-fundas.adoc

@@ -20,7 +20,7 @@ include::partial$build-containers.adoc[tag=greeter]
 
 In the previous chapter we saw how we can deploy services using a holistic service resource file, in this chapter we will see how to deploy the service using configurations and route files.
 
-Navigate to the tutorial chapter's `knative` folder:
+Navigate to the tutorial chapter's folder:
 
 [source,bash,subs="+macros,+attributes"]
 ----

documentation/modules/ROOT/pages/03-configs-and-routes.adoc

@@ -86,7 +86,7 @@ The last `curl` command should return a response like **Hi greeter => greeter-00
 Check <<02-basic-fundas.adoc#see-what-you-have-deployed,deployed Knative resources>> for more details on which Knative objects and resources have been created with the service deployment above.
 
 [#scaling-scale-to-zero]
-== Configure scale to zero 
+== Configure scale-to-zero 
 
 Assuming that <<scaling-deploy-service, Greeter service>> has been deployed, once no more traffic is seen going into that service, we'd like to scale this service down to zero replicas. That's called **scale-to-zero**.
 
@@ -95,7 +95,7 @@ Scale-to-zero is one of the main properties making Knative a serverless platform
 If another request tries to get to this revision, the activator will get it, instruct the autoscaler to create new pods for the revision as quickly as possible and buffer the request until those new pods are created.
 
 [#scale-to-zero-formulae]
-=== Calculating scale to zero time period
+=== Calculating scale-to-zero time period
 
 The Knative autoscaler uses the config map **config-autoscaler** in the **knative-serving** namespace for autoscaling related properties. The values of the attribute `stable-window` and `scale-to-zero-grace-period`, which we've seen above, are part of this config map.
 
@@ -131,6 +131,13 @@ As described above, the time it takes to finally scale to zero will be `STABLE_W
 
 For easier observation let us open a new terminal and run the following command,
 
+[source,bash,subs="+macros,+attributes"]
+----
+watch 'kubectl get pods -n knativetutorial'
+----
+
+.(OR)
+
 [source,bash,subs="+macros,+attributes"]
 ----
 watch 'oc get pods -n knativetutorial'
@@ -147,7 +154,7 @@ echo $STABLE_WINDOW
 echo $SCALE_TO_ZERO_GRACE_PERIOD 
 ----
 
-By default the **scale-to-zero-grace-period** is `30s`, and the **stable-window** is `60s`. Firing a request to the greeter service will bring up the pod (if it is already terminated, as described above) to serve the request. Leaving it without any further requests will automatically cause it to scale to zero in `1 min 30 secs`(<<scale-to-zero-formulae,Compute scale to zero grace period>>).
+By default the **scale-to-zero-grace-period** is `30s`, and the **stable-window** is `60s`. Firing a request to the greeter service will bring up the pod (if it is already terminated, as described above) to serve the request. Leaving it without any further requests will automatically cause it to scale to zero in `1 min 30 secs`(<<scale-to-zero-formulae,Compute scale-to-zero grace period>>).
 
 [#scaling-observer-scale-to-zero-1m]
 === Scale to zero in 1 minute
@@ -189,47 +196,10 @@ oc -n knative-serving get configmap config-autoscaler -o yaml \
   | yq r - data.scale-to-zero-grace-period
 ----
 
-Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request again. Leaving it without any further requests, it will automatically scale to zero in `2 mins`(<<scale-to-zero-formulae,Compute scale to zero grace period>>)
-
-[#scaling-observer-scale-to-zero-2m]
-=== Scale to zero in 2 minute
-
-Let us now update **scale-to-zero-grace-period** to `2m` and leave the **stable-window** to default `60s`.
-
-[source,bash,subs="+macros,+attributes"]
-----
-kubectl -n knative-serving get cm config-autoscaler -o yaml | yq w - -s link:{github-repo}/{scaling-repo}/knative/configure-scaling-to-2m.yaml[configure-scaling-to-2m.yaml] | kubectl apply -f -
-----
-
-.(OR)
-
-[source,bash,subs="+macros,+attributes"]
-----
-oc -n knative-serving get cm config-autoscaler -o yaml | yq w - -s link:{github-repo}/{scaling-repo}/knative/configure-scaling-to-2m.yaml[configure-scaling-to-2m.yaml] | oc apply -f -
-----
-
-Verifying the `scale-to-zero-grace-period` value, which should return `2m`: 
-
-[source,bash,subs="+macros,+attributes",linenums]
-----
-
-kubectl -n knative-serving get configmap config-autoscaler -o yaml \
- | yq r - data.scale-to-zero-grace-period
-----
-
-.(OR)
-
-[source,bash,subs="+macros,+attributes",linenums]
-----
-oc -n knative-serving get configmap config-autoscaler -o yaml \
-  | yq r - data.scale-to-zero-grace-period
-----
-
-
-Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request and if we leave the service without any further requests, it will automatically scale to zero in `3 mins`(<<scale-to-zero-formulae,Compute scale to zero grace period>>).
+Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request again. Leaving it without any further requests, it will automatically scale to zero in `2 mins`(<<scale-to-zero-formulae,Compute scale-to-zero grace period>>)
 
 [#scaling-reset-to-defaults]
-=== Reset scale to zero to defaults
+=== Reset scale-to-zero to defaults
 
 Let us revert the `scale-to-zero-grace-period` to its default:
 
@@ -264,7 +234,7 @@ oc -n knative-serving get configmap config-autoscaler -o yaml \
   | yq r - data.scale-to-zero-grace-period
 ----
 
-For better clarity and understanding let us <<scaling-cleanup,clean up>> the deployed knative resources before going to next section.
+For better clarity and understanding let us <<scaling-cleanup,clean up>> the deployed Knative resources before going to next section.
 
 [#scaling-auto-scaling]
 == Auto Scaling
@@ -340,11 +310,11 @@ watch oc get pods -n knativetutorial
 [#scaling-load-service]
 === Load the service
 
-We will now send some load to the greeter service.  The command below sends 50 concurrent requests (`-c 50`) for the next 10s (`-z 10s`) and test will run for 30 seconds (`-t 30S`)
+We will now send some load to the greeter service.  The command below sends 50 concurrent requests (`-c 50`) for the next 30s (`-t 30s`)
 
 [source,bash,subs="+macros,+attributes",linenums]
 ----
-siege -r 1 -c 50 -t 30S -d 2 \
+siege -r 1 -c 50 -t 30S \
   -H "Host: greeter.knativetutorial.example.com" \
   "http://pass:[${IP_ADDRESS}]"
 ----

documentation/modules/ROOT/pages/04-scaling.adoc

@@ -7,9 +7,9 @@ The raw builds like what we did in xref:ROOT:05-build/build.adoc[previous chapte
  * Hard coding of build parameters 
  * Inability to make builds and services in synchronous i.e. services are deployed only after the related build is complete
 
-One of the solution to these problems is by using **Build Templates**.
+One of the solutions to these problems is **Build Templates**.
 
-Like the build spec the knative build template spec and knative service spec also needs some customizations before apply them.
+Similarly to the build spec, the Knative build template spec and the Knative service spec needs some customizations before being applied.
 
 [#build-template-prerequisite]
 == Prerequisite 
@@ -279,4 +279,4 @@ oc -n knativetutorial delete services.serving.knative.dev event-greeter
 oc -n knativetutorial delete buildtemplates.build.knative.dev build-java-maven
 ----
 
-NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
+NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.

documentation/modules/ROOT/pages/05-build/build-templates.adoc

@@ -19,7 +19,7 @@ Its required that you have container registry account which is needed during the
 You can get one for free at https://hub.docker.com[Docker Hub]
 ====
 
-As the Knative build and build template spec needs some customizations,such as creating a secret with your container registry credentials; we need to run following commands to create the needed kubernetes and knative resources with all your customizations. All the generated files will be placed in `$TUTORIAL_HOME/04-build/knative`.
+As the Knative build and build template specs need some customizations, such as creating a secret with your container registry credentials; we need to run the following commands to create the needed kubernetes and Knative resources with all your customizations. All the generated files will be placed in `$TUTORIAL_HOME/04-build/knative`.
 
 [#build-create-docker-secret]
 == Generate Docker Secret
@@ -72,11 +72,11 @@ type: kubernetes.io/basic-auth
 <2> The username to use when authenticating with https://index.docker.io/v1/
 <3> The password to use when authenticating with https://index.docker.io/v1/
 
-For more details on why we need to do this please check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here].
+For more details on why we need to do this please check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here].
 
 [#build-generate-build-spec]
 == Generate Knative build spec
-The knative build spec is used to create and run the knative builds. You can find more details on Knative build https://github.com/knative/docs/tree/master/build[here].
+The Knative build spec is used to create and run the Knative builds. You can find more details on Knative build https://github.com/knative/docs/tree/master/docs/build[here].
 
 [source,bash,subs="+macros,+attributes",linenums]
 ----
@@ -222,8 +222,8 @@ oc apply -n knativetutorial -f link:{github-repo}/{build-repo}/knative/kaniko-pv
 ----
 
 
-<1> The kubernetes secret called `basic-auth-pass`, check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here] for more details
-<2> The kubernetes service account called `build-bot` that wll run the build.  Only `build-bot` as access to the secret `basic-auth-pass`. Check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here] for more details
+<1> The kubernetes secret called `basic-auth-pass`, check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here] for more details
+<2> The kubernetes service account called `build-bot` that will run the build.  Only `build-bot` has access to the secret `basic-auth-pass`. Check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here] for more details
 <3> the kubernetes persistence volume claim used to cache maven artifacts, to make subsequent builds faster
 <4> the kubernetes persistence volume claim  that will be used to cache docker base images to make subsequent https://github.com/GoogleContainerTools/kaniko[Kaniko] docker builds faster
 

documentation/modules/ROOT/pages/05-build/build.adoc

@@ -22,8 +22,8 @@ spec:
     name: in-memory-channel
 ----
 
-<1> The name of the channel, knative make it addressable i.e. resolveable to a target (a consumer service)
-<2> The channel provisioner which is responsible to provision this channel.Various messaging implementations provide their own channel(s) via __ClusterChannelProvisioner__.
+<1> The name of the channel. Knative makes it addressable, i.e. resolveable to a target (a consumer service)
+<2> The channel provisioner which is responsible for provisioning this channel. Various messaging implementations provide their own channel(s) via __ClusterChannelProvisioner__.
 
 Navigate to tutorial chapter's `knative` folder:
 
@@ -353,4 +353,4 @@ oc -n knativetutorial delete channels.eventing.knative.dev ch-event-greeter
 oc -n knativetutorial delete subscriptions.eventing.knative.dev event-greeter-subscriber
 ----
 
-NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
+NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.

documentation/modules/ROOT/pages/06-eventing/eventing-src-sub.adoc

@@ -114,7 +114,7 @@ Navigate to tutorial chapter's `templates` folder:
 cd $TUTORIAL_HOME/05-eventing/knative/templates
 ----
 
-Run the following command to create the knative service that will be used as the subscriber for the cron events:
+Run the following command to create the Knative service that will be used as the subscriber for the cron events:
 
 [source,bash,subs="+macros,+attributes",linenums]
 ----
@@ -213,4 +213,4 @@ oc -n knativetutorial delete \
  cronjobsources.sources.eventing.knative.dev  event-greeter-cronjob-source
 ----
 
-NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
+NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.