Fix some typos (#152)

asm72 · web-flow · commit 4ceeb1a339c2 · 2022-08-10T12:36:36.000-07:00
diff --git a/assets/certs/component-certs/README.md b/assets/certs/component-certs/README.md
@@ -54,7 +54,7 @@ openssl req -x509  -new -nodes \
   -subj "/C=US/ST=CA/L=MVT/O=TestOrg/OU=Cloud/CN=TestCA"
 ```
 
-3. Check the validatity of the CA
+3. Check the validity of the CA
 
 ```
 openssl x509 -in $TUTORIAL_HOME/generated/cacerts.pem -text -noout
diff --git a/connector/hdfs3-sink-connector/README.md b/connector/hdfs3-sink-connector/README.md
@@ -144,7 +144,7 @@ kubectl --namespace confluent delete -f $TUTORIAL_HOME/hdfs-server.yaml
 
 ## Notes 
 
-Since the Connect leverage the built in libraries of the hadoop client a name for the user of the pod is needed.  
+Since the Connect leverages the built in libraries of the Hadoop client a name for the user of the pod is needed.
 By default Confluent Platform uses ` user ID 1001` which has no name:  
 
 
diff --git a/connector/replicator-with-monitoring/README.md b/connector/replicator-with-monitoring/README.md
@@ -66,7 +66,7 @@ kubectl create secret tls ca-pair-sslcerts \
 In this step you will be creating secrets to be used to authenticate the clusters.  
 
 ```
-# Specify the credentials required by the souce and destination cluster. To understand how these
+# Specify the credentials required by the source and destination cluster. To understand how these
 # credentials are configured, see 
 # https://github.com/confluentinc/confluent-kubernetes-examples/tree/master/security/secure-authn-encrypt-deploy
 
diff --git a/hybrid/ccloud-JDBC-mysql/README.md b/hybrid/ccloud-JDBC-mysql/README.md
@@ -134,7 +134,7 @@ sasl.mechanism=PLAIN
 EOF
 ```
 
-### Create topic to load dat a from table into (CRD connector)
+### Create topic to load data from table into (CRD connector)
 ```
 kafka-topics --command-config /opt/confluentinc/etc/connect/consumer.properties \
 --bootstrap-server CCLOUD:9092  \
@@ -144,7 +144,7 @@ kafka-topics --command-config /opt/confluentinc/etc/connect/consumer.properties
 --topic quickstart-jdbc-CRD-test
 ```
 
-### Create topic to load dat a from table into (REST API endpoint connector) 
+### Create topic to load data from table into (REST API endpoint connector)
 
 ```
 kafka-topics --command-config /opt/confluentinc/etc/connect/consumer.properties \
diff --git a/hybrid/clusterlink/ccloud-as-destination-cluster/README.md b/hybrid/clusterlink/ccloud-as-destination-cluster/README.md
@@ -65,7 +65,7 @@ kubectl -n operator create secret tls ca-pair-sslcerts \
 
 ## CCLOUD setup
 - Create a dedicated a cluster in the Confluent Cloud. Dedicated cluster is required for cluster linking. Standard cluster should be good for creating topics
-- Create an API Key with `Global Access`. You can create API key in `Cluster Overview -> Data Integartion -> API Keys`
+- Create an API Key with `Global Access`. You can create API key in `Cluster Overview -> Data Integration -> API Keys`
 - Create a file `basic.txt` with API Key and API secret in this format
 ```
 username=<API-KEY>
diff --git a/hybrid/clusterlink/ccloud-as-source-cluster/README.md b/hybrid/clusterlink/ccloud-as-source-cluster/README.md
@@ -76,7 +76,7 @@ After the Kafka cluster is in running state, create cluster link between source
 #### exec into destination kafka pod
     kubectl -n destination exec kafka-0 -it -- bash
 
-#### produce a message in the Confuent Cloud topic
+#### produce a message in the Confluent Cloud topic
 Go the UI and produce a message into the topic called demo.
 
 #### consume in destination kafka cluster and confirm message delivery in destination cluster
diff --git a/hybrid/multi-region-clusters/README-basic.md b/hybrid/multi-region-clusters/README-basic.md
@@ -1,6 +1,6 @@
 # MRC Deployment - Basic
 
-In this deploymnet, you'll deploy a quickstart Confluent Platform cluster across a multiple regions set up.
+In this deployment, you'll deploy a quickstart Confluent Platform cluster across a multiple regions set up.
 
 This assumes that you have set up three Kubernetes clusters, and have Kubernetes contexts set up as:
 - mrc-central
diff --git a/hybrid/multi-region-clusters/README.md b/hybrid/multi-region-clusters/README.md
@@ -106,13 +106,13 @@ helm install external-dns -f $TUTORIAL_HOME/external-dns-values.yaml --set names
 
 ## Setup - OpenLDAP
 
-This repo includes a Helm chart for `OpenLdap
+This repo includes a Helm chart for `OpenLDAP
 <https://github.com/osixia/docker-openldap>`. The chart ``values.yaml``
 includes the set of principal definitions that Confluent Platform needs for
 RBAC.
 
 ```
-# Deploy OpenLdap
+# Deploy OpenLDAP
 helm upgrade --install -f $TUTORIAL_HOME/../../assets/openldap/ldaps-rbac.yaml open-ldap $TUTORIAL_HOME/../../assets/openldap -n central --kube-context mrc-central
 
 # Validate that OpenLDAP is running:
diff --git a/hybrid/multi-region-clusters/networking/aks/networking-AKS-README.md b/hybrid/multi-region-clusters/networking/aks/networking-AKS-README.md
@@ -38,7 +38,7 @@ This is the architecture you'll achieve on Azure Kubernetes Service (AKS):
     be the authoritative nameserver for the west.svc.cluster.local domain, and like wise for all pairs of regions.
 
 - Firewall rules
-  - At minimum: allow TCP traffic on the standard ZooKeeper, Kafka and SchemaRegistry ports between all region clusters' Pod subnetworks.
+  - At minimum: allow TCP traffic on the standard Zookeeper, Kafka and SchemaRegistry ports between all region clusters' Pod subnetworks.
 
 In this section, you'll configure the required networking between three Azure Kubernetes Service (AKS) clusters, where 
 each AKS cluster is in a different Azure region.
diff --git a/hybrid/multi-region-clusters/networking/eks/networking-EKS-README.md b/hybrid/multi-region-clusters/networking/eks/networking-EKS-README.md
@@ -13,9 +13,9 @@ This is the architecture you'll achieve on Elastic Kubernetes Service (EKS):
   - For peering to work, address space between VPCs cannot overlap.
   - Additional details on VPC peering can be found here: https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html
 - Flat pod networking
-  - With Amazon VPC Container Networking Interface (CNI), every pod gets an IP address from the subnet and can be accessed directly. 
+  - With Amazon VPC Container Networking Interface (CNI), every pod gets an IP address from the subnet and can be accessed directly.
   - These IP addresses must be unique across your network space. 
-  - Each node can support upto a certain number of pods as defined here: https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt 
+  - Each node can support up to a certain number of pods as defined here: https://github.com/awslabs/amazon-eks-ami/blob/master/files/eni-max-pods.txt
   - The equivalent number of IP addresses per node are then reserved up front for that node.
   - With Amazon VPC CNI, pods do not require a separate address space.
   - Additional details on Amazon VPC CNI can be found here: https://docs.aws.amazon.com/eks/latest/userguide/pod-networking.html
@@ -447,4 +447,4 @@ service "busybox" deleted
 statefulset.apps "busybox" deleted
 service "busybox" deleted
 ```
-With this, the network setup is complete.
+With this, the network setup is complete.
diff --git a/hybrid/multi-region-clusters/networking/gke/networking-GKE-README.md b/hybrid/multi-region-clusters/networking/gke/networking-GKE-README.md
@@ -1,6 +1,6 @@
 # Configure Networking: Google Kubernetes Engine
 
-This is the architecture you'll acheive on Google Kubernetes Engine (GKE):
+This is the architecture you'll achieve on Google Kubernetes Engine (GKE):
 
 - Namespace naming
   - 1 uniquely named namespace in each region cluster
diff --git a/hybrid/replicator/README.md b/hybrid/replicator/README.md
@@ -62,7 +62,7 @@ kubectl create secret tls ca-pair-sslcerts \
 Deploy the source and destination cluster.
 
 ```
-# Specify the credentials required by the souce and destination cluster. To understand how these
+# Specify the credentials required by the source and destination cluster. To understand how these
 # credentials are configured, see 
 # https://github.com/confluentinc/confluent-kubernetes-examples/tree/master/security/secure-authn-encrypt-deploy
 
diff --git a/networking/external-access-load-balancer-deploy/README.rst b/networking/external-access-load-balancer-deploy/README.rst
@@ -136,7 +136,7 @@ The access endpoint of each Confluent Platform component will be:
 
   <Component CR name>.$DOMAIN
 
-For example, in a brower, you will access Control Center at:
+For example, in a browser, you will access Control Center at:
 
 ::
 
diff --git a/security/configure-with-vault/README.md b/security/configure-with-vault/README.md
@@ -22,7 +22,7 @@ Note: Hashicorp Vault is a third party software product that is not supported or
 
 Using the Helm Chart, install the latest version of the Vault server running in development mode to a namespace `hashicorp`.
 
-Running a Vault server in development is automatically initialized and unsealed. This is ideal in a learning environment, but not recomended for a production environment. 
+Running a Vault server in development is automatically initialized and unsealed. This is ideal in a learning environment, but not recommended for a production environment.
 
 ```
 $ kubectl create ns hashicorp
@@ -336,7 +336,7 @@ This repo includes a Helm chart for [OpenLdap](https://github.com/osixia/docker-
 The chart `values.yaml` includes the set of principal definitions that Confluent Platform 
 needs for RBAC.
 
-Deploy OpenLdap:
+Deploy OpenLDAP:
 
 ```
 helm upgrade --install -f $TUTORIAL_HOME/../../assets/openldap/ldaps-rbac.yaml test-ldap $TUTORIAL_HOME/../../assets/openldap -n confluent
diff --git a/security/internal_external-tls_mtls_confluent-rbac/README.md b/security/internal_external-tls_mtls_confluent-rbac/README.md
@@ -129,7 +129,7 @@ In this scenario, you'll be allowing Kafka clients to connect with Kafka through
 For that purpose, you'll provide a server certificate that secures the external domain used for Kafka access.
 
 ```
-# If you dont have one, create a root certificate authority for the external component certs
+# If you don't have one, create a root certificate authority for the external component certs
 openssl genrsa -out $TUTORIAL_HOME/externalRootCAkey.pem 2048
 
 openssl req -x509  -new -nodes \
@@ -248,7 +248,7 @@ kubectl apply -f $TUTORIAL_HOME/controlcenter-testadmin-rolebindings.yaml --name
 # Configure External Access through Ingress Controller
 
 The Ingress Controller will support TLS encryption. For this, you'll need to provide a server certificate
-to use for encypting traffic.
+to use for encrypting traffic.
 
 ```
 # Generate a server certificate from the external root certificate authority
diff --git a/security/userprovided-tls_mtls-sasl_confluent-rbac/README.md b/security/userprovided-tls_mtls-sasl_confluent-rbac/README.md
@@ -41,7 +41,7 @@ kubectl get pods --namespace confluent
 This repo includes a Helm chart for [OpenLdap](https://github.com/osixia/docker-openldap). The chart `values.yaml`
 includes the set of principal definitions that Confluent Platform needs for RBAC.
 
-Deploy OpenLdap:
+Deploy OpenLDAP:
 
 ```
 helm upgrade --install -f $TUTORIAL_HOME/../../assets/openldap/ldaps-rbac.yaml test-ldap $TUTORIAL_HOME/../../assets/openldap --namespace confluent
diff --git a/security/userprovided-tls_mtls_kafka-acls/README.md b/security/userprovided-tls_mtls_kafka-acls/README.md
@@ -46,7 +46,7 @@ These TLS certificates include the following principal names for each component
 - Kafka: `kafka`
 - Schema Registry: `sr`
 - Kafka Connect: `connect`
-- Kafka Rest Pxory: `krp`
+- Kafka Rest Proxy: `krp`
 - ksqlDB: `ksql`
 - Control Center: `controlcenter`
      
@@ -254,7 +254,7 @@ Create ACLs:
 
 # For Connect
 
-### The Connect topic predix is: <namespace>.<connect-cluster-name>-
+### The Connect topic prefix is: <namespace>.<connect-cluster-name>-
 /bin/kafka-acls --bootstrap-server kafka.confluent.svc.cluster.local:9071 \
  --command-config /opt/confluentinc/kafka.properties \
  --add \
@@ -496,7 +496,7 @@ org.apache.kafka.common.errors.TopicAuthorizationException: Not authorized to ac
 
 Check the following:
 1) What principal is being used by the component - this comes from the CN of the certificate used by the component
-2) Are the appopriate ACL created for the components principal
+2) Are the appropriate ACL created for the components principal
 
 To see why Kafka failed the access request, look at the kafka broker logs. 
 You might see messages that indicate authorization failures:
diff --git a/security/using-cert-manager/README.md b/security/using-cert-manager/README.md
@@ -47,7 +47,7 @@ kubectl get pods --namespace confluent
 
 To comprehensively understand how to install cert manager using Helm, see these docs: https://cert-manager.io/docs/installation/kubernetes/
 
-For the purpose of this scenario worklow, use this step to install Cert-manager:
+For the purpose of this scenario workflow, use this step to install Cert-manager:
 
 ```
 kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.0.2/cert-manager.yaml
@@ -59,7 +59,7 @@ kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/relea
 When you provide TLS certificates, CFK takes the provided files and configures Confluent components accordingly.
 
 For each component, the following TLS certificate information should be provided:
-- The certificate authorities for the component to trust, including the authorites used to issue server certificates for any Confluent component cluster. These are required so that peer-to-peer communication (e.g. between Kafka Brokers) and communication between components (e.g. from Connect workers to Kafka) will work.
+- The certificate authorities for the component to trust, including the authorities used to issue server certificates for any Confluent component cluster. These are required so that peer-to-peer communication (e.g. between Kafka Brokers) and communication between components (e.g. from Connect workers to Kafka) will work.
 - The component’s server certificate (public key)
 - The component’s server private key
 
diff --git a/storage/README.md b/storage/README.md
@@ -7,10 +7,10 @@ Before continuing with the scenario, ensure that you have set up the
 
 ## Set the current tutorial directory
 
-Set the tutorial directory under the directory you downloaded this Github repo:
+Set the tutorial directory under the directory you downloaded this GitHub repo:
 
 ```   
-export TUTORIAL_HOME=<Github repo directory>/storage
+export TUTORIAL_HOME=<GitHub repo directory>/storage
 ```
 
 ## Deploy Confluent for Kubernetes
diff --git a/troubleshooting/README.md b/troubleshooting/README.md
@@ -97,7 +97,7 @@ the auto-generated certificate is expired and requires the Operator to be notifi
 
 
 
-### ConfluentRoleBindings associaed with older Kafka cluster
+### ConfluentRoleBindings associated with older Kafka cluster
 
 If CP RBAC enabled Kafka Cluster is deleted and redeployed with same cluster name. Then, all the existing `ConfluentRolebindings` are still associated with previous Kafka Cluster. To make existing `ConfluentRolebindings` sync with new Kafka cluster, you need to manually delete the `KafkaRestClass` and recreate it again.
 
