Typos and fixes

Author: gnunn1

content/modules/ROOT/examples/applicationsets/coolstore-git-appset.yaml

@@ -38,4 +38,5 @@ spec:
                   value: 'gateway-vertx-{{ .values.user }}-{{.path.basename}}'
       syncPolicy:
         automated:
-          prune: true
+          prune: true
+          selfHeal: true          

content/modules/ROOT/pages/04-applicationsets.adoc

@@ -11,9 +11,9 @@ Before we delve into ApplicatioSets, let's dive into the useful link:https://arg
 pattern which predates ApplicationSets. 
 
 The concept of App-of-Apps is that you have an Application in Argo CD that points to a location that consists only of Applications. This enables bootstrapping a set of 
-Applications from a single Application and is useful in use cases such as cluster configuration and multiple environments.
+Applications from a single Application and is useful in use cases such as cluster configuration and same app with multiple environments scenarios.
 
-Before we can deploy the App-of-Apps, we first need to deploy a health check for the Application resource which is not included as an included health check in Argo CD at this time. 
+Before we can deploy the App-of-Apps, we first need to deploy a health check for the Application resource which is not included as a health check in Argo CD at this time. 
 
 [NOTE]
 This is because in Argo CD 1.x the default Application health check was removed, the author of this workshop link:https://github.com/argoproj/argo-cd/issues/16870[disagrees, window="_blank"] with
@@ -35,7 +35,7 @@ argocd.argoproj.io/argocd patched
 
 Next review the applications that the App-of-Apps will be deploying:
 
-[.console-output]
+[.console-input]
 [source,bash,subs="attributes+,+macros"]
 ----
 ls -l ~/workshop/content/modules/ROOT/examples/app-of-apps/base/
@@ -54,7 +54,8 @@ total 12
 There are three Applications defined, one for each environment, with kustomize being used to manage them. If you look at each
 of these Applications note that each environment is tied to a different kustomize overlay matching the destination. This
 provides an opportunity to tweak the manifests for anything specific to an environment. For example, if you look at the overlays
-the `stage` and `prod` environments are patching the vertx-gateway deployment to have two replicas.
+for the `stage` and `prod` environments we are patching the vertx-gateway deployment to have two replicas instead of the default
+one replica defined in the base.
 
 [source,yaml,subs="+macros,attributes+"]
 ----
@@ -76,11 +77,11 @@ application.argoproj.io/coolstore created
 ----
 
 Go to the Argo CD UI, notice that we have four Applications deployed. These include the `coolstore` App-of-Apps as well as the
-three environment Applications that were deployed by `coolstore`.
+three environment specific Applications that were deployed by the `coolstore` App-of-Apps.
 
 image::app-of-apps-tiles.png[]
 
-Click on the `coolstore` tile, notice that it has three resources that it deployed which were the environment Applications.
+Click on the `coolstore` tile, notice that it has three resources that it deployed which were the environment specific Applications.
 
 image::app-of-apps-resources.png[]
 
@@ -134,7 +135,7 @@ and link:https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset
 [#appsets-static]
 === Static Generation with List Generator
 
-Let's look at a simple example of an Application that uses a List generator to create Applications for different environments
+First let's look at a simple example of an Application that uses a List generator to create Applications for different environments
 for the `coolstore` Application. This will be a similar use case to what we saw with App-of-Apps but done
 with ApplicationSets.
 
@@ -231,16 +232,24 @@ where they really shine, dynamic generation based on external sources.
 [#appsets-dynamic]
 === Dynamic Generation with git Generator
 
-A common pattern when deploying an application with kustomize with multiple environments is to have a repository that contains the following structure:
+In this example we will deploy the front-end of the coolstore using an ApplicationSet with the git generator. The
+git generator supports two modes, file and directory. In our case we will leverage the directory mode to
+point the generator at a set of kustomize overlays in the repository.
+
+For those not familiar with kustomize, a common pattern when deploying an application with kustomize for multiple 
+environments is to have a repository that contains a `base` and `overlays` folders. The base folder contains
+all of the manifests to be deployed. The `overlays` are used to patch the base to handle any
+environment specific differences.
+
+The structure of `base` and `overlays` we will be using in this example is as follows:
 
 * *base*: the common assets that we want to deploy
 * *overlays*:
     ** *dev*: specific values that will override the ones in the base for the "dev" environment
     ** *stage*: specific values that will override the ones in the base for the "stage" environment
     ** *prod*: specific values that will override the ones in the base for the "prod" environment
 
-We will be deploying the web frontend for the backend we deployed in the previous section, view the 
-structure in the cloned repository:
+View this structure in the repository that was cloned earlier:
 
 [.console-input]
 [source,sh,subs="attributes",role=execute]
@@ -266,15 +275,16 @@ find ~/workshop/content/modules/ROOT/examples/coolstore-web -print | sort|sed -e
 | | | | | | | | | | |--kustomization.yaml
 ----
 
-Let's deploy these applications using an ApplicationSet as we did previously but this time we will use a git generator. However
-the git generator is somewhat more complex, let's test it locally first.
+Let's deploy these applications using an ApplicationSet using the git generator. However
+the git generator is somewhat more complex then the previous static list example so let's test 
+it locally first to verify that it works.
 
 Output the ApplicationSet to a file replacing the workshop $USER variable with your user:
 
 [.console-input]
 [source,sh,subs="attributes",role=execute]
 ----
-sed 's/$USER/user5/' ~/workshop/content/modules/ROOT/examples/applicationsets/coolstore-git-appset.yaml > ~/appset.yaml
+sed 's/$USER/{user}/' ~/workshop/content/modules/ROOT/examples/applicationsets/coolstore-git-appset.yaml > ~/appset.yaml
 ----
 
 Let's have a quick look at our new ApplicationSet:
@@ -292,7 +302,7 @@ apiVersion: argoproj.io/v1alpha1
 kind: ApplicationSet
 metadata:
   name: coolstore-web
-  namespace: $USER-argocd
+  namespace: {user}-argocd
 spec:
   goTemplate: true
   goTemplateOptions: ["missingkey=error"]
@@ -303,7 +313,7 @@ spec:
       repoURL: https://github.com/OpenShiftDemos/advanced-gitops-workshop <3>
       revision: HEAD
       values:
-        user: $USER <4>
+        user: {user} <4>
   template:
     metadata:
       name: coolstore-web-{{.path.basename}} <5>
@@ -329,6 +339,7 @@ spec:
       syncPolicy:
         automated:
           prune: true
+          selfHeal: true          
 ----
 <1> We are using the git generator to create an Application for every directory in the target repository and path
 <2> The target path, each sub-directory in this path will be used to create an application. In our case the `dev` and `prod` overlays
@@ -375,7 +386,7 @@ Now that the generation has been verified, go ahead and deploy it:
 [.console-input]
 [source,sh,subs="attributes",role=execute]
 ----
-sed 's/$USER/{user}/' ~/workshop/content/modules/ROOT/examples/applicationsets/coolstore-appset-git.yaml | oc apply -n {user}-argocd -f - 
+sed 's/$USER/{user}/' ~/workshop/content/modules/ROOT/examples/applicationsets/coolstore-git-appset.yaml | oc apply -n {user}-argocd -f - 
 ----
 
 Check that the Applications have been created: