Merge pull request #640 from mbaldessari/typos

Fix a bunch of grammatical errors

Author: mbaldessari

content/blog/2022-09-02-route.md

@@ -45,7 +45,7 @@ As you can see the spec describes the a **host:**  or path to the route, the tar
 
 If we focus on the **host:** value you see that we need to provide the Ingress_Domain to the host. You might ask yourself: *why is this a problem?*
 
-If you manage just one cluster, and your application just runs on that cluster, you can just hard code the ingress domain and be on your merry way.  But what happens when you are deploying this application to multiple clusters and their domains are different?  Whoever is doing the Ops to deploy your application will have to change the Ingress_Domain to match the the cluster domain manually before deploying the application.
+If you manage just one cluster, and your application just runs on that cluster, you can just hard code the ingress domain and be on your merry way.  But what happens when you are deploying this application to multiple clusters and their domains are different?  Whoever is doing the Ops to deploy your application will have to change the Ingress_Domain to match the cluster domain manually before deploying the application.
 
 Let's go a step further and say you are using *GitOps*, and this definition lives in a *git* repository, what happens then? In our humble opinion it becomes a bit more complicated to make sure the ingress domain is set correctly.
 

content/blog/2023-11-17-argo-configmanagement-plugins.md

@@ -133,7 +133,7 @@ cluster that will be running the demo can be discovered, so rather than requirin
 mechanism that extracted that information and stored it as a Helm variable. Meanwhile, the components of industrial-edge
 that used this information had very opinionated kustomize-based deployment mechanisms and workflows to update them.
 We did not want to change this mechanism at the time, so it was better for us to work out how to apply Helm templating
-on top of a set of of manifests that kustomize had already rendered. The CMP 1.0 framework was suitable for this, and
+on top of a set of manifests that kustomize had already rendered. The CMP 1.0 framework was suitable for this, and
 fairly straightforward to use, so we did. However, we did not, at that time, put any thought into parameterizing the
 use of config management plugins; making too radical a change to how the repo server worked would have difficult, and
 would have required injecting a new (and unsupported) image into a product; not something to be undertaken lightly.

content/blog/2023-12-05-nutanix-testing.md

@@ -23,6 +23,6 @@ Pattern consumers can now rest assured that the core pattern functionality will
 
 This would not be possible without the wonderful co-operation of Nutanix, who are doing all the work of deploying OpenShift and our pattern on their platform, executing the tests, and reporting the results.
 
-To facilitate this, the patterns team have begun the process of open sourcing the downstream tests for all our patterns.  Soon all tests will live alongside the the patterns they target, allowing them to be easily executed and/or improved by pattern consumers and platform owners.
+To facilitate this, the patterns team have begun the process of open sourcing the downstream tests for all our patterns.  Soon all tests will live alongside the patterns they target, allowing them to be easily executed and/or improved by pattern consumers and platform owners.
 
 Our thanks once again to Nutanix.

content/blog/2024-01-26-more-secrets-options.md

@@ -62,7 +62,7 @@ loaded by the appropriate backend code.
 Users of the pattern framework will be able to change secrets backends as straightforwardly
 as we can make possible. The only other change the user will need to make (to use another
 ESO backend) is to use the backend's mechanism to refer to keys. (For example: in Vault,
-keys have have names like `secret/data/global/config-demo`; in the Kubernetes backend
+keys have names like `secret/data/global/config-demo`; in the Kubernetes backend
 it would just be the secret object name that's being used to store the secret material,
 such as `config-demo`).
 
@@ -297,7 +297,7 @@ and running them.
 
 `k8s_secret_utils` is used for loading both the `kubernetes` and `none` backends. It
 
-### Changes to to vault_utils Ansible Role
+### Changes to vault_utils Ansible Role
 
 Some code has been factored out of `vault_utils` and now lives in roles called `cluster_pre_check` and
 `find_vp_secrets` roles. A new task file has been added, `push_parsed_secrets.yaml` that knows how to use

content/blog/2024-07-12-in-cluster-git.md

@@ -64,7 +64,7 @@ There are fundamentally two ways to set up the in-cluster gitea server.
 
 ## Configuration
 
-Once the the in-gitea cluster is enabled, its configuration will be done via a normal argo application
+Once the in-cluster gitea is enabled, its configuration will be done via a normal argo application
 that can be seen in the cluster-wide argo:
 ![gitea-argo-application](/images/gitea-argocd-application.png)
 

content/patterns/ansible-edge-gitops-kasten/cluster-sizing.md

@@ -46,7 +46,7 @@ Here's an inventory of what gets deployed by the **Ansible Edge GitOps** pattern
 
 The Ansible Edge GitOps pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
 
-The Hub OpenShift Cluster is made up of the the following on the AWS deployment tested:
+The Hub OpenShift Cluster is made up of the following on the AWS deployment tested:
 
 | Node Type | Number of nodes | Cloud Provider | Instance Type
 | :---- | :----: | :---- | :----

content/patterns/ansible-edge-gitops-kasten/getting-started.md

@@ -101,7 +101,7 @@ secrets:
         chpasswd: { expire: False }
 ```
 
-* A manifest file with an entitlement to run Ansible Automation Platform. This file (which will be a .zip file) will be posted to to Ansible Automation Platform instance to enable its use.  Instructions for creating a manifest file can be found [here](https://www.redhat.com/en/blog/how-create-and-use-red-hat-satellite-manifest)
+* A manifest file with an entitlement to run Ansible Automation Platform. This file (which will be a .zip file) will be posted to Ansible Automation Platform instance to enable its use.  Instructions for creating a manifest file can be found [here](https://www.redhat.com/en/blog/how-create-and-use-red-hat-satellite-manifest)
 
 ```yaml
   - name: aap-manifest

content/patterns/ansible-edge-gitops-kasten/openshift-virtualization.md

@@ -339,7 +339,7 @@ Click on the "three dots" menu on the right, which will open a dialog like the f
 
 [![kubevirt411-vm-open-console](/images/ansible-edge-gitops/aeg-kubevirt411-con-ignition.png)](/images/ansible-edge-gitops/aeg-kubevirt411-con-ignition.png)
 
-The virtual machine console view will either show a standard RHEL console login screen, or if the demo is working as designed, it will show the Ignition application running in kiosk mode. If the console shows a standard RHEL login, it can be accessed using the the initial user name (`cloud-user` by default) and password (which is what is specified in the Helm chart Values as either the password specific to that machine group, the default cloudInit, or a hardcoded default which can be seen in the template [here](https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/charts/hub/edge-gitops-vms/templates/virtual-machines.yaml). On a VM created through the wizard or via `oc process` from a template, the password will be set on the VirtualMachine object in the `volumes` section.
+The virtual machine console view will either show a standard RHEL console login screen, or if the demo is working as designed, it will show the Ignition application running in kiosk mode. If the console shows a standard RHEL login, it can be accessed using the initial user name (`cloud-user` by default) and password (which is what is specified in the Helm chart Values as either the password specific to that machine group, the default cloudInit, or a hardcoded default which can be seen in the template [here](https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/charts/hub/edge-gitops-vms/templates/virtual-machines.yaml). On a VM created through the wizard or via `oc process` from a template, the password will be set on the VirtualMachine object in the `volumes` section.
 
 ### Initial User login (cloud-user)
 

content/patterns/devsecops/cluster-sizing.md

@@ -36,7 +36,7 @@ The hub can be modified to deploy OpenShift Pipelines if needed. See Development
 
 The Secure Supply Chain pattern has been tested with a defined set of specifically tested configurations that represent the most common combinations that Red Hat OpenShift Container Platform (OCP) customers are using or deploying for the x86_64 architecture.
 
-The Hub OpenShift Cluster is made up of the the following on the AWS deployment tested:
+The Hub OpenShift Cluster is made up of the following on the AWS deployment tested:
 
 | Node Type | Number of nodes | Cloud Provider | Instance Type
 | :---- | :----: | :---- | :----

content/patterns/devsecops/devel-cluster.md

@@ -66,4 +66,4 @@ There are a number of steps you can do to check that the components have deploye
 
 ## Next up
 
-Deploy the the Multicluster DevSecOps [secured production cluster](/devsecops/production-cluster)
+Deploy the Multicluster DevSecOps [secured production cluster](/devsecops/production-cluster)