Merge pull request #2737 from jkleckner/more-spelling

Nit fix spelling of separate

CHANGELOG.md

@@ -16,7 +16,7 @@ Core Features:
 * --limit can now be given a filename (--limit @filename) to constrain a run to a host list on disk
 * failed playbook runs will create a retry file in /var/tmp/ansible usable with --limit
 * roles allow easy arrangement of reusable tasks/handlers/files/templates
-* pre_tasks and post_tasks allow for seperating tasks into blocks where handlers will fire around them automatically
+* pre_tasks and post_tasks allow for separating tasks into blocks where handlers will fire around them automatically
 * "meta: flush_handler" task capability added for when you really need to force handlers to run
 * new --start-at-task option to ansible playbook allows starting at a specific task name in a long playbook
 
@@ -172,7 +172,7 @@ Module Changes/Fixes:
 * more OS X facts
 * added a 'fail_on_missing' (default no) option to fetch
 * added timeout to the uri module (default 30 seconds, adjustable)
-* ec2 now has a 'wait' parameter to wait for the instance to be active, eliminates need for seperate wait_for call.
+* ec2 now has a 'wait' parameter to wait for the instance to be active, eliminates need for separate wait_for call.
 * allow regex backreferences in lineinfile
 * id attribute on ec2 module can be used to set idempotent-do-not-recreate launches
 * icinga support for nagios module

docsite/latest/rst/bestpractices.rst

@@ -133,7 +133,7 @@ We can define specific hardware variance in systems in a host_vars file, but avo
     foo_agent_port: 86
     bar_agent_port: 99
 
-Top Level Playbooks Are Seperated By Role
+Top Level Playbooks Are Separated By Role
 `````````````````````````````````````````
 
 In site.yml, we include a playbook that defines our entire infrastructure.  Note this is SUPER short, because it's just including
@@ -230,12 +230,12 @@ to be some additional playbooks that hop between tiers to roll out an applicatio
 may be augmented by playbooks like 'deploy_exampledotcom.yml' but the general concepts can still apply.
 
 Ansible allows you to deploy and configure using the same tool, so you would likely reuse groups and just
-keep the OS configuration in seperate playbooks from the app deployment.
+keep the OS configuration in separate playbooks from the app deployment.
 
 Stage vs Production
 +++++++++++++++++++
 
-As also mentioned above, a good way to keep your stage (or testing) and production environments seperate is to use a seperate inventory file for stage and production.   This way you pick with -i what you are targetting.  Keeping them all in one file can lead to surprises!
+As also mentioned above, a good way to keep your stage (or testing) and production environments separate is to use a separate inventory file for stage and production.   This way you pick with -i what you are targetting.  Keeping them all in one file can lead to surprises!
 
 Testing things in a stage environment before trying in production is always a great idea.  Your environments need not be the same
 size and you can use group variables to control the differences between those environments.

library/add_host

@@ -16,7 +16,7 @@ options:
   groups:
     aliases: [ 'groupname' ]
     description:
-    - The groups to add the hostname to, comma seperated.
+    - The groups to add the hostname to, comma separated.
     required: false
 author: Seth Vidal
 examples: