Merge pull request #6769 from ericdahl/docs-typos

Documentation: fix various small typos

docsite/rst/faq.rst

@@ -246,7 +246,7 @@ Great question!  Documentation for Ansible is kept in the main project git repos
 How do I keep secret data in my playbook?
 +++++++++++++++++++++++++++++++++++++++++
 
-If you would like to keep secret data in your Ansible content and still share it publically or keep things in source control, see :doc:`playbooks_vault`.
+If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :doc:`playbooks_vault`.
 
 .. _i_dont_see_my_question:
 

docsite/rst/guide_rax.rst

@@ -579,7 +579,7 @@ Autoscaling with Tower
 
 :doc:`tower` also contains a very nice feature for auto-scaling use cases.  
 In this mode, a simple curl script can call a defined URL and the server will "dial out" to the requester 
-and configure an instance that is spinning up.  This can be a great way to reconfigure ephmeral nodes.  
+and configure an instance that is spinning up.  This can be a great way to reconfigure ephemeral nodes.
 See the Tower documentation for more details.  
 
 A benefit of using the callback in Tower over pull mode is that job results are still centrally recorded 

docsite/rst/guide_rolling_upgrade.rst

@@ -172,7 +172,7 @@ Here's another example, from the same template::
    {% endfor %}
 
 This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for 
-each monitoring hosts's default IPV4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
+each monitoring hosts' default IPV4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts.
 
 You can learn a lot more about Jinja2 and its capabilities `here <http://jinja.pocoo.org/docs/>`_, and you 
 can read more about Ansible variables in general in the :doc:`playbooks_variables` section.
@@ -184,7 +184,7 @@ The Rolling Upgrade
 
 Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's 
 orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible
-referes to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it.  
+refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it.
 
 Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_upgrade.yml``.
 
@@ -201,7 +201,7 @@ The next part is the update play. The first part looks like this::
      user: root
      serial: 1
 
-This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will paralleize these operations up to the default "forks" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time.
+This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default "forks" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time.
 
 Here is the next part of the update play::
 

docsite/rst/guide_vagrant.rst

@@ -7,7 +7,7 @@ Introduction
 ````````````
 
 Vagrant is a tool to manage virtual machine environments, and allows you to
-configure and use reproducable work environments on top of various
+configure and use reproducible work environments on top of various
 virtualization and cloud platforms. It also has integration with Ansible as a
 provisioner for these virtual machines, and the two tools work together well.
 

docsite/rst/guides.rst

@@ -12,5 +12,5 @@ This section is new and evolving.  The idea here is explore particular use cases
    guide_vagrant
    guide_rolling_upgrade
 
-Pending topics may include: Docker, Jenkins, Google Compute Engine, Linode/Digital Ocean, Continous Deployment, and more.
+Pending topics may include: Docker, Jenkins, Google Compute Engine, Linode/Digital Ocean, Continuous Deployment, and more.
 

docsite/rst/guru.rst

@@ -3,7 +3,7 @@ Ansible Guru
 
 While many users should be able to get on fine with the documentation, mailing list, and IRC, sometimes you want a bit more.
 
-`Ansible Guru <http://ansible.com/ansible-guru>`_ is an offering from Ansible, Inc that helps users who would like more dedicated help with Ansible, including building playbooks, best practices, architecture suggestions, and more -- all from our awesome support and services team.  It also includes some useful discounts and also some free T-shirts, though you shoudn't get it just for the free shirts!  It's a great way to train up to becoming an Ansible expert.
+`Ansible Guru <http://ansible.com/ansible-guru>`_ is an offering from Ansible, Inc that helps users who would like more dedicated help with Ansible, including building playbooks, best practices, architecture suggestions, and more -- all from our awesome support and services team.  It also includes some useful discounts and also some free T-shirts, though you shouldn't get it just for the free shirts!  It's a great way to train up to becoming an Ansible expert.
 
 For those interested, click through the link above.  You can sign up in minutes!
 

docsite/rst/playbooks_variables.rst

@@ -880,7 +880,7 @@ See :doc:`playbooks_roles` for more info about this::
 
     ---
     # file: roles/x/defaults/main.yml
-    # if not overriden in inventory or as a parameter, this is the value that will be used
+    # if not overridden in inventory or as a parameter, this is the value that will be used
     http_port: 80
 
 if you are writing a role and want to ensure the value in the role is absolutely used in that role, and is not going to be overridden