Add set option description, add grammar fixes

docs/cdev-vs-pulumi.md

@@ -6,11 +6,11 @@ These are great tools and we admire alternative views on infrastructure manageme
 
 What makes Cluster.dev different is its purpose and limitations. 
 Tools like Pulumi, Crossplane, and Terraform are aimed to manage clouds - creating new instances or clusters, cloud resources like databases, and others. 
-While Cluster.dev is designed to manage the whole infrastructure, including those tools as units. That means you can run Terraform, then run Pulumi, or Bash, or Ansible with variables received from Terraform, and then run Crossplane or something else. Cluster.dev is created to connect and manage all infrastructure tools. 
+Cluster.dev however is designed to manage the whole infrastructure, including those tools as units. That means you can run Terraform, then run Pulumi, or Bash, or Ansible with variables received from Terraform, and then run Crossplane or something else. Cluster.dev is created to connect and manage all infrastructure tools. 
 
-With infrastructure tools, users are often restricted with one-tool usage that has specific language or DSL. Whereas Cluster.dev allows to have a limitless number of units and workflow combinations between tools. 
+With infrastructure tools, users are often restricted with one-tool usage that has a specific language or DSL, whereas Cluster.dev allows to have a limitless number of units and workflow combinations between tools. 
 
-For now Cluster.dev has a major support for Terraform only, mostly because we want to provide the best experience for the majority of users. Moreover, Terraform is a de-facto industry standard and already has a lot of modules created by the community. 
-To read more on the subject please refer to [Cluster.dev vs. Terraform](https://docs.cluster.dev/cdev-vs-terraform/) section.
+For now, Cluster.dev has major support for Terraform only, mainly because we want to provide the best experience for the majority of users. Moreover, Terraform is a de-facto industry standard and already has many modules created by the community. 
+To read more on the subject please refer to the [Cluster.dev vs. Terraform](https://docs.cluster.dev/cdev-vs-terraform/) section.
 
 If you or your company would like to use Pulumi or Crossplane with Cluster.dev, please feel free to [contact us](https://calendly.com/clusterdev/30min?month=2021-11). 

docs/cdev-vs-terraform.md

@@ -4,29 +4,30 @@ Terraform is a great and popular tool for creating infrastructures. Despite the
 
 Cluster.dev loves Terraform (and even supports export to the plain Terraform code). Still, Terraform lacks a robust relation system, fast plans, automatic reconciliation, and configuration templates. 
 
-Cluster.dev, on the other hand, is a managing software that uses Terraform alongside other infrastructure tools as building blocks. 
+Cluster.dev, on the other hand, is a management software that uses Terraform alongside other infrastructure tools as building blocks. 
 
 As a higher abstraction, Cluster.dev fixes all listed problems: builds a single source of truth, and combines and orchestrates different infrastructure tools under the same roof.  
 
-Let's dig more into the problems that Cluster.dev solves.
+Let's dig further into the problems that Cluster.dev solves.
 
 ## Internal relation 
 
-As Terraform has pretty complex rendering logic, it affects the relations between its pieces. For example, you cannot define a provider for, let say, k8s or Helm, in the same codebase that creates a k8s cluster. This forces users to resort to internal hacks or employ a custom wrapper to have two different deploys — that is a problem we solved via Cluster.dev. 
+As Terraform has pretty complex rendering logic, it affects the relations between its pieces. For example, you cannot define a provider for, let say, k8s or Helm, in the same codebase that creates a k8s cluster. This forces users to resort to internal hacks or having to employ a custom wrapper to have two different deploys — that is a problem we solved via Cluster.dev. 
 
 Another problem with internal relations concerns huge execution plans that Terraform creates for massive projects. Users who tried to avoid this issue by using small Terraform repos, faced the challenges of weak "remote state" relations and limited possibilities of reconciliation: it was not possible to trigger a related module, if the output of the module it relied upon had been changed.
 
-On the contrary, Cluster.dev allows you to trigger only the necessary parts, as it is a GitOps-first tool. 
+Cluster.dev however allows you to trigger only the necessary parts, as it is a GitOps-first tool. 
 
 ## Templating
 
-The second limitation of Terraform is templating: Terraform doesn’t support templating of tf files that it uses. This forces users to hacks that further tangle their Terraform files. 
-And while Cluster.dev uses templating, it allows to include, let’s say, Jenkins Terraform module with custom inputs for dev environment and not to include it for staging and production — all in the same codebase. 
+The second limitation of Terraform is templating: Terraform doesn’t support templating of tf files that it uses. This forces users to perform hacks that further tangle their Terraform files. 
+As for the Cluster.dev templating, it allows to include, let’s say, Jenkins Terraform module with custom inputs for dev environment and not to include it for staging and production — all in the same codebase. 
 
 ## Third Party
 
 Terraform allows for executing Bash or Ansible. However, it doesn't contain many instruments to control where and how these external tools will be run. 
 
-While Cluster.dev as a cloud native manager provides all tools the same level of support and integration. 
+Cluster.dev as a cloud native manager on the other hand provides all tools with the same level of support and integration.
+
 
 

docs/examples-modify-aws-eks.md

@@ -2,7 +2,7 @@
 
 *The code and the text prepared by [Orest Kapko](https://github.com/AlKapkone), a DevOps engineer at SHALB.*  
 
-In this article we shall customize the basic [AWS-EKS Cluster.dev template](https://github.com/shalb/cdev-aws-eks) in order to add some features.
+In this section we shall customize the basic [AWS-EKS Cluster.dev template](https://github.com/shalb/cdev-aws-eks) in order to add some features.
 
 ## Workflow steps
 
@@ -62,7 +62,7 @@ In this article we shall customize the basic [AWS-EKS Cluster.dev template](http
     }
       ```
 
-4. As it was decided to use Traefik Ingress controller instead of basic Nginx, we spun up two load balancers (first - internet-facing ALB for public ingresses, and second - internal ALB for private ingresses) and security groups necessary for its work, and described them in albs unit. The unit configuration within the template:
+4. As it was decided to use Traefik Ingress controller instead of basic Nginx, we spun up two load balancers (first - internet-facing ALB for public ingresses, and second - internal ALB for private ingresses) and security groups necessary for its work, and described them in albs unit. The unit configuration within the template is as follows:
 
     ```yaml
     {{- if .variables.ingressControllerEnabled }}
@@ -81,7 +81,7 @@ In this article we shall customize the basic [AWS-EKS Cluster.dev template](http
     {{- end }}
     ```
 
-5. Also we have created a dedicated unit for testing Ingress through Route 53 records:
+5. We have also created a dedicated unit for testing Ingress through Route 53 records:
 
     ```yaml
     data "aws_route53_zone" "existing" {

docs/units-helm.md

@@ -40,17 +40,17 @@ In addition to common options the following are available:
 * `chart`, `repository`, `version` - correspond to options with the same name from helm_release resource. See [chart](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#chart), [repository](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#repository) and [version](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#version).
 
 * `kubeconfig` - *string*, *required*. Path to the kubeconfig file which is relative to the directory where the unit was executed.
-* `provider_version` - *string*, *optional*. Version of terraform helm provider to use. Default - latest. See [terraform helm provider](https://registry.terraform.io/providers/hashicorp/helm/latest)  
+* `provider_version` - *string*, *optional*. Version of Terraform Helm provider to use. Default - latest. See [terraform helm provider](https://registry.terraform.io/providers/hashicorp/helm/latest)  
 
 * `additional_options` - *map of any*, *optional*. Corresponds to [Terraform helm_release resource options](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#argument-reference). Will be passed as is.
 
 * `values` - *array*, *optional*. List of values (file name or values data) to be passed to Helm. Values will be merged, in order, as Helm does with multiple -f options.
 
-    * `set` - *map of any*, *required one of set/file*. Set of helm values.
+    * `set` - *map of any*, *required one of set/file*. Set of Helm values. This option allows you to transfer the value of the Helm chart without saving it to a file.
 
     * `file` - *string*, *required one of set/file*. Path to the values file.
 
-    * `apply_template` - *bool*, *optional*. Defines whether a template should be applied to the values file. By default is set to `true`. Used only with `file` option
+    * `apply_template` - *bool*, *optional*. Defines whether a template should be applied to the values file. By default is set to `true`. Used only with `file` option.
 
 * `inputs` - *map of any*, *optional*. A map that represents [Terraform helm_release sets](https://registry.terraform.io/providers/hashicorp/helm/latest/docs/resources/release#set). This block allows to use functions `remoteState` and `insertYAML`. For example: