Spelling errors and so on.

docs/chart_template_guide/accessing_files.md

@@ -193,7 +193,7 @@ data:
 
 ## Lines
 
-Sometimes it is desireable to access each line of a file in your template. We
+Sometimes it is desirable to access each line of a file in your template. We
 provide a convenient `Lines` method for this.
 
 ```yaml

docs/chart_template_guide/control_structures.md

@@ -271,7 +271,7 @@ It will produce an error because `Release.Name` is not inside of the restricted
 
 After looking a `range`, we will take a look at template variables, which offer one solution to the scoping issue above.
 
-## Looping with the the `range` action
+## Looping with the `range` action
 
 Many programming languages have support for looping using `for` loops, `foreach` loops, or similar functional mechanisms. In Helm's template language, the way to iterate through a collection is to use the `range` operator.
 

docs/chart_template_guide/debugging.md

@@ -9,7 +9,7 @@ There are a few commands that can help you debug.
 - `helm get manifest`: This is a good way to see what templates are installed on the server.
 
 When your YAML is failing to parse, but you want to see what is generated, one
-easy way to retrieve the YAML is to commet out the problem section in the template,
+easy way to retrieve the YAML is to comment out the problem section in the template,
 and then re-run `helm install --dry-run --debug`:
 
 ```YAML

docs/chart_template_guide/yaml_techniques.md

@@ -267,7 +267,7 @@ Some files in Helm cannot contain more than one doc. If, for example, more
 than one document is provided inside of a `values.yaml` file, only the first
 will be used.
 
-Template files, however, may have more than one document. When this happends,
+Template files, however, may have more than one document. When this happens,
 the file (and all of its documents) is treated as one object during
 template rendering. But then the resulting YAML is split into multiple
 documents before it is fed to Kubernetes.

docs/charts.md

@@ -559,7 +559,7 @@ As a chart developer, you may author charts that are specifically designed
 to be used as starters. Such charts should be designed with the following
 considerations in mind:
 
-- The `Chart.yaml` will be overwritten by the genertor.
+- The `Chart.yaml` will be overwritten by the generator.
 - Users will expect to modify such a chart's contents, so documentation
   should indicate how users can do so.
 

docs/helm/helm_fetch.md

@@ -13,7 +13,7 @@ also be used to perform cryptographic verification of a chart without installing
 the chart.
 
 There are options for unpacking the chart after download. This will create a
-directory for the chart and uncomparess into that directory.
+directory for the chart and uncompress into that directory.
 
 If the --verify flag is specified, the requested chart MUST have a provenance
 file, and MUST pass the verification process. Failure in any part of this will

docs/helm/helm_history.md

@@ -11,7 +11,7 @@ History prints historical revisions for a given release.
 A default maximum of 256 revisions will be returned. Setting '--max'
 configures the maximum length of the revision list returned.
 
-The historical release set is printed as a formatted table, e.g:
+The historical release set is printed as a formatted table, e.g.:
 
     $ helm history angry-bird --max=4
     REVISION   UPDATED                      STATUS           CHART

docs/helm/helm_install.md

@@ -24,7 +24,7 @@ To check the generated manifests of a release without installing the chart,
 the '--debug' and '--dry-run' flags can be combined. This will still require a
 round-trip to the Tiller server.
 
-If --verify is set, the chart MUST have a provenance file, and the provenenace
+If --verify is set, the chart MUST have a provenance file, and the provenance
 fall MUST pass all verification steps.
 
 There are four different ways you can express the chart you want to install:

docs/helm/helm_verify.md

@@ -8,7 +8,7 @@ verify that a chart at the given path has been signed and is valid
 
 Verify that the given chart has a valid provenance file.
 
-Provenance files provide crytographic verification that a chart has not been
+Provenance files provide cryptographic verification that a chart has not been
 tampered with, and was packaged by a trusted provider.
 
 This command can be used to verify a local chart. Several other commands provide

docs/plugins.md

@@ -164,7 +164,7 @@ these flags are _not_ passed on to the plugin.
 
 - `--debug`: If this is specified, `$HELM_DEBUG` is set to `1`
 - `--home`: This is converted to `$HELM_HOME`
-- `--host`: This is convereted to `$HELM_HOST`
+- `--host`: This is converted to `$HELM_HOST`
 - `--kube-context`: This is simply dropped. If your plugin uses `useTunnel`, this
   is used to set up the tunnel for you.
 

docs/using_helm.md

@@ -224,7 +224,7 @@ the rest of the defaults for that chart.
 
 There are two ways to pass configuration data during install:
 
-- `--values` (or `-f`): Specifiy a YAML file with overrides.
+- `--values` (or `-f`): Specify a YAML file with overrides.
 - `--set`: Specify overrides on the command line.
 
 If both are used, `--set` values are merged into `--values` with higher precedence.

pkg/storage/driver/cfgmaps.go

@@ -311,7 +311,7 @@ func decodeRelease(data string) (*rspb.Release, error) {
 	return &rls, nil
 }
 
-// logerrf wraps an error with the a formatted string (used for debugging)
+// logerrf wraps an error with a formatted string (used for debugging)
 func logerrf(err error, format string, args ...interface{}) {
 	log.Printf("configmaps: %s: %s\n", fmt.Sprintf(format, args...), err)
 }