fixing spelling

shrielenee · Jun 25, 2015 · e18dd6b · e18dd6b
1 parent 3add9c9
commit e18dd6b
Showing 5 changed files with 17 additions and 18 deletions.
diff --git a/concepts.md b/concepts.md
diff --git a/docs/cloudservices.md b/docs/cloudservices.md
@@ -18,15 +18,15 @@ For Example:
 coreo_aws_vpc_vpc "my-vpc" do
   action :sustain
   cidr "12.0.0.0/16"
-  internet_gateway true
+  Internet_gateway true
 end
 ```
 In the above example, CloudCoreo would create a VPC with the CIDR address of "12.0.0.0/16" and attach an *internet gateway* to the VPC to allow traffic to the public subnets (which haven't been defined in this specific example).
 
 This is all very inflexible in terms of cloning, which is why ***templating*** has been built into the system.
 
 ### Templating System
-Templateing allows variables to be inserted into the system at runtime, thus allowing a single template to be used in many different environements. The substitution comes from one of:
+Templating allows variables to be inserted into the system at runtime, thus allowing a single template to be used in many different environments. The substitution comes from one of:
 
 1. The value provided by the user in the CloudCoreo UI
 1. The values set during the run of the CLI tool
@@ -44,7 +44,7 @@ end
 ```
 Within your config.yaml file, you can now call out a `VPC_NAME` variable and apply defaults. This variable name will show up in the web UI for any users to modify.
 ### Overriding Resources
-The `services/` directory honors the heirarchy we have discussed elsewhere. The difference, however, is that in the `config.rb` file each ***resource*** is overridable on an individual basis. This is best explained with an example.
+The `services/` directory honors the hierarchy we have discussed elsewhere. The difference, however, is that in the `config.rb` file each ***resource*** is over-ridable on an individual basis. This is best explained with an example.
 
 Lets say we have the following directory structure and files:
 
@@ -87,9 +87,9 @@ end
 The point of this is that the *key* is the first line, in this case `coreo_aws_vpc_vpc "${VPC_NAME}" do`. This means that as CloudCoreo is compiling the resources, it will see the ***VPC*** resource in the root ***last*** and will replace any existing blocks with this same resource key. The important part is that CloudCoreo will honor the positioning of the resources that it is overriding and simply override the block. We call this ***anchoring***.
 
 ### Anchoring
-Anchoring is what CloudCoreo does with overridden resources. The key (`<resource> "<name>" do`) that is being overriden becomes an anchor for all pre-requisite resources found in an overriding file. That's a mouthful. Here's an abstract example. Please do not pay attention to the blocks because they are irrelevant and shortened for clarity.
+Anchoring is what CloudCoreo does with overridden resources. The key (`<resource> "<name>" do`) that is being overridden becomes an anchor for all pre-requisite resources found in an overriding file. That's a mouthful. Here's an abstract example. Please do not pay attention to the blocks because they are irrelevant and shortened for clarity.
 
-Begin again with our standard directory struture we have been using:
+Begin again with our standard directory structure we have been using:
 
 * `<repository-dir>/extends/services/config.rb`
 and
@@ -141,7 +141,7 @@ coreo_aws_ec2_elb 'my-elb' do
 end
 ```
 
-The ***anchor*** in this is the elb resource. What this means is that anything above that has not already overridden something will be considered a prerequisite of the resource doing the overrideing (the key). This means that the root level `services/config.rb` file's coreo_aws_ec2_elb resource block will override the one found in the `extends/services/config.rb` file. Not only that, but all the resources above the key in the root level will maintain order and override with the key. The final compliation will be a merge of the two files with the *anchor* located in the same place as the orriginal, with any other non-overriding resources preceding it from the overriding file. Here is what the compiled version would become.
+The ***anchor*** in this is the elb resource. What this means is that anything above that has not already overridden something will be considered a prerequisite of the resource doing the overriding (the key). This means that the root level `services/config.rb` file's coreo_aws_ec2_elb resource block will override the one found in the `extends/services/config.rb` file. Not only that, but all the resources above the key in the root level will maintain order and override with the key. The final compilation will be a merge of the two files with the *anchor* located in the same place as the original, with any other non-overriding resources preceding it from the overriding file. Here is what the compiled version would become.
 ```
 coreo_aws_vpc_subnet 'public-subnet' do
    vpc 'my-vpc'
@@ -173,5 +173,5 @@ end
 ```
 The '*public-subnet*' resource has been included from the `extends/services/config.rb` file, while the '*my-elb*' from the `extends/services/config.rb` essentially *becomes* the '*private-subnet*' + '*my-elb-sg*' + '*my-elb*'.
 
-### Api Docs
+### API Docs
 If you are working on services within CloudCoreo, you need to know what options, parameters etc you can use. For those head over to our [API Documentation](http://docs.cloudcoreo.com/docs/frames/index).
diff --git a/docs/configurationfiles.md b/docs/configurationfiles.md
@@ -1,5 +1,5 @@
 ## Configuration Files
-There are a few configuration files that exist in the CloudCoreo convention. These files are all overrideable.
+There are a few configuration files that exist in the CloudCoreo convention. These files are all override-able.
 
 ### Variable Config
 Defined by the `config.yaml` file.
@@ -10,7 +10,7 @@ The `config.yaml` file defines variables for the stack. It resides in the `<repo
 Defined by the `order.yaml` file is the configuration file that travels along with and is located in the `boot-scripts` directory. The format is *yaml* which means that **tab indentations are an error**. Here is an example:
 ```
 order:
-    - install_packges.sh
+    - install_packages.sh
     - run_chef.sh
 ```
-CloudCoreo will run (as root) each script in order. The proccess is to **chmod +x** the files and run with a **./<filename>** so make sure the shebang is correct.
+CloudCoreo will run (as root) each script in order. The process is to **chmod +x** the files and run with a **./<filename>** so make sure the shebang is correct.
diff --git a/docs/directorystructure.md b/docs/directorystructure.md
@@ -1,20 +1,20 @@
 ## Directory Structure
-CloudCoreo relies on convention over configuartaion for the most part. Each repository can contain whatever you like, which is useful for running scripts or laying down code you rely on. There are some directories that we reserve the right to, and this is a list of those directories as well as whay they do.
+CloudCoreo relies on convention over configuration for the most part. Each repository can contain whatever you like, which is useful for running scripts or laying down code you rely on. There are some directories that we reserve the right to, and this is a list of those directories as well as what they do.
 
 The directory structure has much to do with how CloudCoreo works. The convention we have defined dictates what gets overridden, what runs during boot of a server, what runs as Cloud Services, etc. The [CLI Tool](https://github.com/CloudCoreo/cloudcoreo-cli) will do much of the work for you, but you should still know what it all means.
 
 ### extends
-The `extends` directory is one of the most basic but importanct concepts in CloudCoreo. This is how you are able to **leverage the work of others** and bring it all within your own deployment.
+The `extends` directory is one of the most basic but important concepts in CloudCoreo. This is how you are able to **leverage the work of others** and bring it all within your own deployment.
 
 The simple way to think about `extends` is as the base for anything you are doing in this stack. In other words, **any and all work defined in `extends` will be completed before moving on to the parent directory**.
 
 ### stack-*
-Any subdirectory begining with `stack-` is reserved in CloudCoreo. The work in these directories is completed **after** the `extends` directory (if it exists) but before anything else in the current repository. This makes it suitable to *add an external stack* to your stack.
+Any subdirectory beginning with `stack-` is reserved in CloudCoreo. The work in these directories is completed **after** the `extends` directory (if it exists) but before anything else in the current repository. This makes it suitable to *add an external stack* to your stack.
 
 When adding a stack, you must be considerate of the future needs of people *overriding* and *extending* and/or extending your stack. This actually doesn't mean anything other than the fact that you can make everyones life easier in the future by creating blank directories in which they can add their own bits of code and overrides. In order to ease the administration efforts of creating these directories, the CLI tool does the following with the `stack-`. 
 
 #### What does this all mean? An example
-Lets assume you want to add a stack from git (github.com:example/tomcat.git) into your own and call it `tomcat`. The directory structure that would ease this for future use is to create a `stack-tomcat` directory to signify it is special within the CloudCoreo framework. Next, create an `extends` directory inside and extend the stack into this directory. This is actually utilizing both concepts. Because you have used a `stack-*` directory to the `<repository-dir>`, it will get run **after** the `<repository-dir>/extends`. Because you have added the stack to the `<repository-dir>/stack-tomcat/extends` it will run **before** everything else inside the `stack-tomcat* directory. This gives anyone utilizing your stack a conveninent place to insert configuration and setup between your stack and the added tomcat stack.
+Lets assume you want to add a stack from git (github.com:example/tomcat.git) into your own and call it `tomcat`. The directory structure that would ease this for future use is to create a `stack-tomcat` directory to signify it is special within the CloudCoreo framework. Next, create an `extends` directory inside and extend the stack into this directory. This is actually utilizing both concepts. Because you have used a `stack-*` directory to the `<repository-dir>`, it will get run **after** the `<repository-dir>/extends`. Because you have added the stack to the `<repository-dir>/stack-tomcat/extends` it will run **before** everything else inside the `stack-tomcat* directory. This gives anyone utilizing your stack a convenient place to insert configuration and setup between your stack and the added tomcat stack.
 
 ### services
 The `services` directory exists to define the stack's interaction with the cloud provider in which the server is launched. Specifically, the `<repository-dir>/services/config.rb` file. This is in-depth enough to contain its own documentation section.
@@ -35,7 +35,7 @@ CloudCoreo will run each script in the `extends/stack-example/extends/boot-scrip
 The files contained within the `<repository-dir>/operational-scripts` directory are scripts you would like to be able to run on an ad-hoc basis from the CloudCoreo GUI or CLI. The structure and scripts within this directory honor the order and overrides defined within the rest of this document.
 
 ### shutdown-scripts
-The `<repository-dir>/shutdown-scripts` directory contains scripts that CloudCoreo will **attempt** to run. These are not gaurenteed because many times failures are a complete loss of a system with no warning. The structure and scripts within this directory honor the order and overrides defined within the rest of this document.
+The `<repository-dir>/shutdown-scripts` directory contains scripts that CloudCoreo will **attempt** to run. These are not guaranteed because many times failures are a complete loss of a system with no warning. The structure and scripts within this directory honor the order and overrides defined within the rest of this document.
 
 ### overrides
 Anything contained in this directory will act as an override for the stack in which it is contained.

diff --git a/docs/overview.md b/docs/overview.md
@@ -1,9 +1,9 @@
 # The Stack
-'Stack' is, admitedly, very much an overused term in our industry. It seems that for some reason, everyone is quick to redefine it. 
+'Stack' is, admittedly, very much an over used term in our industry. It seems that for some reason, everyone is quick to redefine it. 
 
 ...and we are no different!
 
-A 'stack' for us is everything in your cloud deployment. ***Virtutual Machines*** are a given, but we include *everything else* as well. What does *everything else* actually mean? Well, *evertyhing*.
+A 'stack' for us is everything in your cloud deployment. ***Virtual Machines*** are a given, but we include *everything else* as well. What does *everything else* actually mean? Well, *everything*.
 
 * Networks
 * Managed Services