chore: fix some comments

README.md

@@ -159,7 +159,7 @@ cfg, err: = builder.
     Build()
 ```
 
-Since we support both `eth1` (aka pre-Merge) and `eth2` (aka post-Merge) client versions, you need to specify which one you want to use. You can do that by calling `WithEthereumVersion` method. There's no default provided. The only execption is when you use custom docker images (instead of default ones), because then we can determine which version it is based on the image version.
+Since we support both `eth1` (aka pre-Merge) and `eth2` (aka post-Merge) client versions, you need to specify which one you want to use. You can do that by calling `WithEthereumVersion` method. There's no default provided. The only exception is when you use custom docker images (instead of default ones), because then we can determine which version it is based on the image version.
 
 If you want your test to execute as fast as possible go for `eth1` since it's either using a fake PoW or PoA consensus and is much faster than `eth2` which uses PoS consensus (where there is a minimum viable length of slot/block, which is 4 seconds; for `eth1` it's 1 second). If you want to test the latest features, changes or forks in the Ethereum network and have your tests running on a network which is as close as possible to Ethereum Mainnet, go for `eth2`.
 
@@ -379,7 +379,7 @@ When running tests in CI you're probably interested in grouping logs by test exe
 
 ## Test Summary
 
-In order to facilitate displaying information in GH's step summary `testsummary` package was added. It exposes a single function `AddEntry(testName, key string, value interface{}) `. When you call it, it either creates a test summary JSON file or appends to it. The result is is a map of keys with values.
+In order to facilitate displaying information in GH's step summary `testsummary` package was added. It exposes a single function `AddEntry(testName, key string, value interface{}) `. When you call it, it either creates a test summary JSON file or appends to it. The result is a map of keys with values.
 
 Example:
 

charts/besu-prysm/README.md

@@ -1,7 +1,7 @@
 # VERY IMPORTANT
 **There needs to be least one node labeled with `eth2=true` for deployment to work! (see below how to do it)**
 
-# Deployment initalisation flow
+# Deployment initialisation flow
 Each `StatefulSet` has the same `initContainers` that are responsible for:
 1. Generating validator keys
 2. Generating eth1 and eth2 genesis

charts/geth-non-root/Readme.md

@@ -1,6 +1,6 @@
 # Raison d'etre
 
-This chart allows to run a geth node as a non-root user, which is esential for running it on more secure clusters. Geth is running as Proof-of-Authority private network with a single node. By default ingress is disabled, so remember to enable it in `values.yaml`.
+This chart allows to run a geth node as a non-root user, which is essential for running it on more secure clusters. Geth is running as Proof-of-Authority private network with a single node. By default ingress is disabled, so remember to enable it in `values.yaml`.
 
 Sample command:
 ```bash

charts/geth-prysm/README.md

@@ -1,4 +1,4 @@
-# Deployment initalisation flow
+# Deployment initialisation flow
 Each `StatefulSet` has the same `initContainers` that are responsible for:
 1. Generating validator keys
 2. Generating eth1 and eth2 genesis

docs/debug/eth2.md

@@ -1,6 +1,6 @@
 # Prysm containers
 
-Docker images provided by Prysm are bare-bone and do not even contain exectuable shell, which makes debugging impossible. To overcome it we need to build our own image with debug tools installed. The following Dockerfile will do the job for `beacon chain`:
+Docker images provided by Prysm are bare-bone and do not even contain executable shell, which makes debugging impossible. To overcome it we need to build our own image with debug tools installed. The following Dockerfile will do the job for `beacon chain`:
 
 ```
 ARG tag
@@ -67,6 +67,6 @@ docker run -it --rm --privileged --pid=host justincormack/nsenter1
 ```
 
 (Other options are described [here](https://gist.github.com/BretFisher/5e1a0c7bcca4c735e716abf62afad389))
-Then you need to find find a folder where `rootfs` for Docker VM is located, in my case it was `/containers/services/02-docker/rootfs` (search for a folder containing whatever hostpath you have the persistent volumne mounted at, or inspect one of your pods, check the volume mount and find it in the VM, just remember that even if your volume is supposedly mounted in `/data/shared` on the host in reality that `/data/shared` folder is still relative to wherever `rootfs` folder is located).
+Then you need to find find a folder where `rootfs` for Docker VM is located, in my case it was `/containers/services/02-docker/rootfs` (search for a folder containing whatever hostpath you have the persistent volume mounted at, or inspect one of your pods, check the volume mount and find it in the VM, just remember that even if your volume is supposedly mounted in `/data/shared` on the host in reality that `/data/shared` folder is still relative to wherever `rootfs` folder is located).
 
 Once you find it, you can delete the old data and start the service again. Or you can use it for debugging to easily inspect the content of shared volumes (useful in case of containers that are bare-bone and don't even have `bash` installed, like Prysm).

k8s/imports/k8s/httpchaos/chaosmeshorg/chaosmeshorg.go

@@ -383,7 +383,7 @@ type HttpChaosSpecReplace struct {
 	Headers *map[string]*string `field:"optional" json:"headers" yaml:"headers"`
 	// Method is a rule to replace http method in request.
 	Method *string `field:"optional" json:"method" yaml:"method"`
-	// Path is rule to to replace uri path in http request.
+	// Path is rule to replace uri path in http request.
 	Path *string `field:"optional" json:"path" yaml:"path"`
 	// Queries is a rule to replace uri queries in http request.
 	//

k8s/imports/k8s/k8s.go

@@ -258,7 +258,7 @@ type CertificateSigningRequestSpec struct {
 	SignerName *string `field:"required" json:"signerName" yaml:"signerName"`
 	// expirationSeconds is the requested duration of validity of the issued certificate.
 	//
-	// The certificate signer may issue a certificate with a different validity duration so a client must check the delta between the notBefore and and notAfter fields in the issued certificate to determine the actual duration.
+	// The certificate signer may issue a certificate with a different validity duration so a client must check the delta between the notBefore and notAfter fields in the issued certificate to determine the actual duration.
 	//
 	// The v1.22+ in-tree implementations of the well-known Kubernetes signers will honor this field as long as the requested duration is not greater than the maximum duration they will honor per the --cluster-signing-duration CLI flag to the Kubernetes controller manager.
 	//
@@ -10929,7 +10929,7 @@ type KubeCsiStorageCapacityV1Alpha1Props struct {
 	MaximumVolumeSize Quantity `field:"optional" json:"maximumVolumeSize" yaml:"maximumVolumeSize"`
 	// Standard object's metadata.
 	//
-	// The name has no particular meaning. It must be be a DNS subdomain (dots allowed, 253 characters). To ensure that there are no conflicts with other CSI drivers on the cluster, the recommendation is to use csisc-<uuid>, a generated name, or a reverse-domain name which ends with the unique CSI driver name.
+	// The name has no particular meaning. It must be a DNS subdomain (dots allowed, 253 characters). To ensure that there are no conflicts with other CSI drivers on the cluster, the recommendation is to use csisc-<uuid>, a generated name, or a reverse-domain name which ends with the unique CSI driver name.
 	//
 	// Objects are namespaced.
 	//
@@ -11249,7 +11249,7 @@ type KubeCsiStorageCapacityV1Beta1Props struct {
 	MaximumVolumeSize Quantity `field:"optional" json:"maximumVolumeSize" yaml:"maximumVolumeSize"`
 	// Standard object's metadata.
 	//
-	// The name has no particular meaning. It must be be a DNS subdomain (dots allowed, 253 characters). To ensure that there are no conflicts with other CSI drivers on the cluster, the recommendation is to use csisc-<uuid>, a generated name, or a reverse-domain name which ends with the unique CSI driver name.
+	// The name has no particular meaning. It must be a DNS subdomain (dots allowed, 253 characters). To ensure that there are no conflicts with other CSI drivers on the cluster, the recommendation is to use csisc-<uuid>, a generated name, or a reverse-domain name which ends with the unique CSI driver name.
 	//
 	// Objects are namespaced.
 	//