[CI] Publish Documentation for 10fadf2 - 10fadf2 🚀

argo-rollouts-workshop/main/02-workshop-overview.html

@@ -273,7 +273,7 @@ <h2 id="review-rollout-manager"><a class="anchor" href="#review-rollout-manager"
 <i class="fa icon-note" title="Note"></i>
 </td>
 <td class="content">
-Argo Rollouts can be deployed as ether a namespace or cluster scope, the OpenShift GitOps operator
+Argo Rollouts can be deployed as either a namespace or cluster scope, the OpenShift GitOps operator
 currently only supports namespace scope.
 </td>
 </tr>
@@ -294,7 +294,8 @@ <h2 id="review-rollout-manager"><a class="anchor" href="#review-rollout-manager"
 <i class="fa icon-note" title="Note"></i>
 </td>
 <td class="content">
-We are using a kubectl plugin called <a href="https://github.com/itaysk/kubectl-neat" target="_blank" rel="noopener">kubectl-neat</a>
+The <code>oc</code> CLI tool is a superset of <code>kubectl</code> with some additional Openshift specific features. We will use <code>oc</code> in this tutorial but if you prefer you can use <code>kubectl</code> as well.
+In the previous command we are using a kubectl plugin called <a href="https://github.com/itaysk/kubectl-neat" target="_blank" rel="noopener">kubectl-neat</a>
 in order to tidy the yaml by removing additional fields, labels and annotations added automatically by Kubernetes.
 </td>
 </tr>
@@ -558,7 +559,7 @@ <h3 id="_deploy_development"><a class="anchor" href="#_deploy_development"></a>D
 </div>
 <div class="paragraph">
 <p>Copy the URL into a browser and confirm that the application is running, you should see a grid of
-blue squares appearing and disappearing periodically as the application makes requests to it&#8217;s back-end
+blue squares appearing and disappearing periodically as the application makes requests to its back-end
 from the browser.</p>
 </div>
 <div class="imageblock">

argo-rollouts-workshop/main/03-bluegreen-rollout.html

@@ -246,12 +246,11 @@ <h2 id="blue-green-strategy"><a class="anchor" href="#blue-green-strategy"></a>B
 </div>
 </div>
 <div class="paragraph">
-<p>In traditional infrastructure this approach can be very challenging. While Kubernetes is simpler due to it&#8217;s declarative nature the process still tends to be cumbersome to manage since bespoke automation needs to be created to manage the separate stacks,
+<p>In traditional infrastructure this approach can be very challenging. While Kubernetes is simpler due to its declarative nature, the process still tends to be cumbersome to manage. Bespoke automation would still need to be created to manage the separate stacks, and for
 testing and traffic management between versions.</p>
 </div>
 <div class="paragraph">
-<p>This is where Argo Rollouts comes in, it greatly reduces the complexity by providing these capabilities with a simple, declarative approach. In this module
-we will deploy a simple blue-green Rollout and explore it&#8217;s basic capabilities.</p>
+<p>This is where Argo Rollouts comes in. It greatly reduces the complexity by providing these capabilities with a simple, declarative approach. In this module we will deploy a simple blue-green Rollout and explore its basic capabilities.</p>
 </div>
 </div>
 </div>
@@ -317,11 +316,11 @@ <h2 id="deploy-blue-green-rollout"><a class="anchor" href="#deploy-blue-green-ro
 and <code>replace</code> strategies whereas Argo Rollouts supports <code>blueGreen</code> and <code>canary</code> strategies.</p>
 </div>
 <div class="paragraph">
-<p>Under the <code>blueGreen</code> strategy we have identified the <code>active</code> and <code>preview</code> Kubernetes services for the rollout which will be covered
+<p>Under the <code>blueGreen</code> strategy we have identified the <code>active</code> and <code>preview</code> Kubernetes services for the rollout. This will be covered
 in more detail when services are discussed next.</p>
 </div>
 <div class="paragraph">
-<p>As well as services the field <code>autoPromotionEnabled</code> is set to <code>false</code> which means the rollout will require manual intervention to promote. Manual promotion
+<p>The field <code>autoPromotionEnabled</code> is set to <code>false</code>. This means the rollout will require manual intervention to promote. Manual promotion
 is enabled so the behavior of the rollout can be observed in-depth in subsequent sections of this module.</p>
 </div>
 <div class="paragraph">
@@ -432,7 +431,7 @@ <h2 id="deploy-blue-green-rollout"><a class="anchor" href="#deploy-blue-green-ro
 <i class="fa icon-note" title="Note"></i>
 </td>
 <td class="content">
-We are getting pods using the label <code>app=rollouts-demo</code> to specifically select pods from the rollout, remember
+We are getting pods using the label <code>app=rollouts-demo</code> to specifically select pods from the rollout. Remember
 the RolloutManager pod is also deployed in the <code>user%USERNUM%-prod</code> namespace. Using the label enables us
 to exclude that pod.
 </td>
@@ -515,12 +514,12 @@ <h2 id="deploy-blue-green-rollout"><a class="anchor" href="#deploy-blue-green-ro
 </div>
 <div class="paragraph">
 <p>Notice that the selector now has an additional key, <code>rollouts-pod-template-hash</code>, with a hashed value. This is how the rollout manages traffic
-between the active and preview versions. Since we have not deployed a new image, if you check the preview service you will see the same
+between the active and preview versions. Since we have not deployed a new image, the preview service will have the same
 selector used there as well.</p>
 </div>
 <div class="paragraph">
 <p>Similar to Kubernetes deployments, each revision, i.e. version, of the Rollout is backed by a <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" target="_blank" rel="noopener">ReplicaSet</a>.
-This ReplicaSet will have a <code>rollouts-pod-template-hash</code> label in it&#8217;s PodTemplate with a value unique to the revision. Argo Rollouts will automatically ensure that
+This ReplicaSet will have a <code>rollouts-pod-template-hash</code> label in its PodTemplate with a value unique to the revision. Argo Rollouts will automatically ensure that
 the selector in the service is pointing to the appropriate revision.</p>
 </div>
 <div class="paragraph">
@@ -657,7 +656,7 @@ <h3 id="argo-rollouts-dashboard"><a class="anchor" href="#argo-rollouts-dashboar
 </table>
 </div>
 <div class="paragraph">
-<p>In the dashboard each rollout will show in it&#8217;s own tile on the overview screen. The tile will provide some
+<p>In the dashboard each rollout will show in its own tile on the overview screen. The tile will provide some
 basic information about the rollout as shown here:</p>
 </div>
 <div class="imageblock">
@@ -716,7 +715,7 @@ <h2 id="promote-image"><a class="anchor" href="#promote-image"></a>Promote Image
 <td class="content">
 This pipeline is not meant to be a comprehensive example of how to manage image promotion, rather we
 are using it provide a simple way in the workshop to drive image changes. This pipeline uses OpenShift
-Pipelines however any Continuous Integration(CI) tool can be used with Argo Rollouts including Argo Workflows,
+Pipelines, an implementation of the <a href="https://tekton.dev" target="_blank" rel="noopener">Tekton</a> project, however any Continuous Integration(CI) tool can be used with Argo Rollouts including Argo Workflows,
 GitHub Actions, GitLab, etc.
 </td>
 </tr>
@@ -768,7 +767,7 @@ <h2 id="promote-image"><a class="anchor" href="#promote-image"></a>Promote Image
 </div>
 <div class="paragraph">
 <p>Now let&#8217;s see what the application looks like in production where we are using Rollouts. First, let&#8217;s check the preview service by
-retrieving it&#8217;s URL and viewing it in the browser:</p>
+retrieving its URL and viewing it in the browser:</p>
 </div>
 <div class="listingblock console-input">
 <div class="content">

argo-rollouts-workshop/main/04-analysis.html

@@ -240,15 +240,15 @@ <h2 id="analysis-overview"><a class="anchor" href="#analysis-overview"></a>Analy
 new version of the application.</p>
 </div>
 <div class="paragraph">
-<p>In addition to collecting data, an Analysis can include a Job to drive more advanced use cases. For example
+<p>In addition to collecting data, an Analysis can include a Job to drive more advanced use cases. For example,
 a Job could be used to run load against an application in order to generate the metrics needed to
 validate the revision.</p>
 </div>
 <div class="paragraph">
 <p>To deploy an Analysis, first an AnalysisTemplate is created that defines the analysis that is required
 and then is associated with one or more rollouts. The way an analysis is associated with a rollout is dependent on
 the rollout strategy used. In this module we will look at it from the perspective of the Blue-Green
-strategy we have deployed previously however in the next module we delve into it for the Canary strategy as well.</p>
+strategy we have deployed previously. In the next module we will delve into using an Analysis with the Canary strategy as well.</p>
 </div>
 <div class="paragraph">
 <p>In the blue-green strategy, an Analysis can be added as either pre-promotion or post-promotion. Pre-promotion
@@ -347,14 +347,13 @@ <h2 id="analysis-deployment"><a class="anchor" href="#analysis-deployment"></a>A
 </ul>
 </div>
 <div class="paragraph">
-<p>In the metrics provider section we can see we have two providers defined, one that uses the prometheus metric provider to pull
-metrics from Thanos, an aggregator for Prometheus data, and a job that runs <a href="https://github.com/JoeDog/siege" target="_blank" rel="noopener">Apache Siege</a>
+<p>In the metrics provider section we can see that we have two providers defined. The first one, named <code>success-rate</code>, uses the prometheus metric provider to pull metrics from Thanos, an aggregator for Prometheus data. The second one, <code>run-load</code> is a job that runs <a href="https://github.com/JoeDog/siege" target="_blank" rel="noopener">Apache Siege</a>
 to drive some load on the application.</p>
 </div>
 <div class="paragraph">
 <p>The <code>count</code> and <code>interval</code> fields in the <code>success-rate</code> metric powered by the prometheus provider indicate that the metric will be checked four times
 with a thirty second interval between each check. The <code>failureLimit</code> determines how many failures are permitted for the rollout to be considered
-a success, here we set a failure limit of 0.</p>
+a success. Here we set a failure limit of 0.</p>
 </div>
 <div class="paragraph">
 <p>Finally, remember we are running this Analysis in the pre-promotion phase of the blue-green strategy so the application will not
@@ -377,7 +376,7 @@ <h2 id="analysis-deployment"><a class="anchor" href="#analysis-deployment"></a>A
 </div>
 <div class="paragraph">
 <p>Finally a third parameter, <code>api-token</code>, is provided by a secret. This secret provides the token needed
-to access the OpenShift monitoring stack, it was created by the GitOps process which provisioned this workshop.</p>
+to access the OpenShift monitoring stack. It was created by the GitOps process which provisioned this workshop.</p>
 </div>
 <div class="paragraph">
 <p>Next let&#8217;s look at the rollout and see how the AnalysisTemplate is wired into the rollout.</p>
@@ -431,7 +430,7 @@ <h2 id="analysis-deployment"><a class="anchor" href="#analysis-deployment"></a>A
 template.</p>
 </div>
 <div class="paragraph">
-<p>Next to deploy this new version of the blue-green rollout, execute the following command:</p>
+<p>To deploy this new version of the blue-green rollout, execute the following command:</p>
 </div>
 <div class="listingblock console-input">
 <div class="content">
@@ -456,7 +455,7 @@ <h2 id="analysis-deployment"><a class="anchor" href="#analysis-deployment"></a>A
 </div>
 </div>
 <div class="paragraph">
-<p>Next confirm that the application is displaying blue squares by opening the active route URL in your browser:</p>
+<p>Confirm that the application is displaying blue squares by opening the active route URL in your browser:</p>
 </div>
 <div class="listingblock console-input">
 <div class="content">
@@ -507,9 +506,9 @@ <h3 id="_analysis_passes"><a class="anchor" href="#_analysis_passes"></a>Analysi
 <div class="paragraph">
 <p>When a promotion of a rollout with an analysis is executed the controller will
 generate an analysis run for each template execution. Since we only have one template
-being used in pre-promotion we will only see one analysis run being created however
-it is possible for a promotion to have multiple analysis runs dependent on the
-rollout configuration, i.e. in blue-green defining both pre and post promotion analysis.</p>
+being used in pre-promotion we will only see one analysis run being created.
+It is however possible for a promotion to have multiple analysis runs, dependent on the
+rollout configuration. i.e. in blue-green defining both pre and post promotion analysis.</p>
 </div>
 <div class="paragraph">
 <p>Clicking on the analysis button will expand the view to show the in-progress analysis
@@ -634,9 +633,9 @@ <h3 id="_analysis_fails"><a class="anchor" href="#_analysis_fails"></a>Analysis
 <td class="content">
 This section should not be overly timing sensitive since we are
 cheating a bit by pre-generating errors. However when we promote the new image the error
-setting will be reset back to 0 for the preview service. After the promotion pipeline completes,
+setting will be reset back to 0 for the preview service. <strong>After the promotion pipeline completes,
 immediately switch back to the tab with the preview service and push the error bar
-back to 100%.
+back to 100%</strong>.
 </td>
 </tr>
 </table>
@@ -671,7 +670,7 @@ <h3 id="_analysis_fails"><a class="anchor" href="#_analysis_fails"></a>Analysis
 </td>
 <td class="content">
 If the timing did not work out for you, you can try again by promoting with a different color.
-You can see the list of available colors .<a href="https://quay.io/repository/openshiftdemos/rollouts-demo?tab=tags" target="_blank" rel="noopener">here</a>
+You can see the list of available colors <a href="https://quay.io/repository/openshiftdemos/rollouts-demo?tab=tags" target="_blank" rel="noopener">here</a>
 where each color is simply a tag in our quay.io registry.
 </td>
 </tr>

argo-rollouts-workshop/main/05-canary-rollout.html

@@ -234,8 +234,8 @@ <h2 id="canary-strategy"><a class="anchor" href="#canary-strategy"></a>Canary St
 <div class="sectionbody">
 <div class="paragraph">
 <p><a href="https://argo-rollouts.readthedocs.io/en/stable/features/canary/" target="_blank" rel="noopener">Canary</a> can be
-thought of as an advanced version of blue-green where instead of an abrupt cut-over
-of live traffic between a current and new revision traffic is instead gradually increased to the new
+thought of as an advanced version of blue-green. Instead of an abrupt cut-over
+of live traffic between a current and new revision, traffic is instead gradually increased to the new
 version in increments, or steps, while simultaneously decreasing the current revision. Like the
 proverbial <a href="https://en.wiktionary.org/wiki/canary_in_a_coal_mine" target="_blank" rel="noopener">canary in the coal mine</a>,
 the intent is to allow users to access the new version over time and if unexpected problems occur revert back to the
@@ -337,8 +337,8 @@ <h2 id="deploy-canary-rollout"><a class="anchor" href="#deploy-canary-rollout"><
 </div>
 </div>
 <div class="paragraph">
-<p>In the rollout we have changed our strategy from blue-green to canary. In the canary strategy, like the blue-green strategy, we specify
-the services to use however here they are stable and canary services. Unlike blue-green we explicitly define the promotion process by
+<p>In the rollout manifest we have changed our strategy from blue-green to canary. In the canary strategy, like the blue-green strategy, we specify
+the services to use however here they are <code>stable</code> and <code>canary</code> services. Unlike blue-green we explicitly define the promotion process by
 specifying a series of discrete steps. At each step we can set the traffic weight between the services, pause or perform an
 inline analysis.</p>
 </div>
@@ -704,7 +704,7 @@ <h2 id="promote-image"><a class="anchor" href="#promote-image"></a>Promote Image
 </div>
 </div>
 <div class="paragraph">
-<p>Observe the dashboard once it has been promoted, the dashboard will show the progression
+<p>Observe the dashboard once it has been promoted. The dashboard will show the progression
 of the steps by highlighting each step as it is being executed. Also note how pods are
 being drained from one service to the other as traffic weighting changes.</p>
 </div>
@@ -740,13 +740,13 @@ <h2 id="inline-analysis"><a class="anchor" href="#inline-analysis"></a>Inline An
 or as an <a href="https://argo-rollouts.readthedocs.io/en/stable/features/analysis/#inline-analysis">inline</a> analysis.</p>
 </div>
 <div class="paragraph">
-<p>A background analysis happens asynchronously and does not block the progression of steps, however
+<p>A Background Analysis happens asynchronously and does not block the progression of steps, however
 if the analysis fails it will abort the rollout similar to what we saw in the previous module with
-the blue-green strategy. In the case of an inline analysis, the analysis is performed as a discrete step
+the blue-green strategy. In the case of an Inline Analysis, the analysis is performed as a discrete step
 and will block the progression of the rollout until it completes.</p>
 </div>
 <div class="paragraph">
-<p>The files for this example are in the <code>./canary-analysis/base</code> folder, to view the list of files
+<p>In the following example we will implement an Inline Analysis. The files for this example are in the <code>./canary-analysis/base</code> folder, to view the list of files
 perform an <code>ls</code> as follows:</p>
 </div>
 <div class="listingblock console-input">
@@ -755,7 +755,7 @@ <h2 id="inline-analysis"><a class="anchor" href="#inline-analysis"></a>Inline An
 </div>
 </div>
 <div class="paragraph">
-<p>Note that the files are identical to the previous example other then the <code>rollout.yaml</code> and the
+<p>Note that the files are identical to the previous example other than the <code>rollout.yaml</code> and the
 <code>analysistemplate.yaml</code> file. The AnalysisTemplate being used here is identical to the one
 we used in the blue-green example so we will not cover it again here.</p>
 </div>

sitemap.xml

@@ -2,30 +2,30 @@
 <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/01-getting-started.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/02-workshop-overview.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/03-bluegreen-rollout.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/04-analysis.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/05-canary-rollout.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/06-conclusion.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 <url>
 <loc>https://openshiftdemos.github.io/argo-rollouts-workshop/argo-rollouts-workshop/main/index.html</loc>
-<lastmod>2024-01-09T20:42:39.776Z</lastmod>
+<lastmod>2024-03-08T15:41:35.581Z</lastmod>
 </url>
 </urlset>