From 9309b6b0e469f721717b74e673a601a57f1e9879 Mon Sep 17 00:00:00 2001 From: Eric Dahl Date: Sun, 30 Mar 2014 18:45:55 -0500 Subject: [PATCH] Documentation: fix various small typos --- docsite/rst/faq.rst | 2 +- docsite/rst/guide_rax.rst | 2 +- docsite/rst/guide_rolling_upgrade.rst | 6 +++--- docsite/rst/guide_vagrant.rst | 2 +- docsite/rst/guides.rst | 2 +- docsite/rst/guru.rst | 2 +- docsite/rst/playbooks_variables.rst | 2 +- 7 files changed, 9 insertions(+), 9 deletions(-) diff --git a/docsite/rst/faq.rst b/docsite/rst/faq.rst index 13ab9437cdb..af9d4930600 100644 --- a/docsite/rst/faq.rst +++ b/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: diff --git a/docsite/rst/guide_rax.rst b/docsite/rst/guide_rax.rst index 37ca6b796c6..66381bbf843 100644 --- a/docsite/rst/guide_rax.rst +++ b/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 diff --git a/docsite/rst/guide_rolling_upgrade.rst b/docsite/rst/guide_rolling_upgrade.rst index b464ef11a42..f730e8d7899 100644 --- a/docsite/rst/guide_rolling_upgrade.rst +++ b/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 `_, 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:: diff --git a/docsite/rst/guide_vagrant.rst b/docsite/rst/guide_vagrant.rst index 4fb40d569f2..9472b74dd2f 100644 --- a/docsite/rst/guide_vagrant.rst +++ b/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. diff --git a/docsite/rst/guides.rst b/docsite/rst/guides.rst index 0585d966097..cf9c821bdbb 100644 --- a/docsite/rst/guides.rst +++ b/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. diff --git a/docsite/rst/guru.rst b/docsite/rst/guru.rst index 4267396c94a..e4f07fd3478 100644 --- a/docsite/rst/guru.rst +++ b/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 `_ 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 `_ 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! diff --git a/docsite/rst/playbooks_variables.rst b/docsite/rst/playbooks_variables.rst index 0ab668135cf..3b5907e3301 100644 --- a/docsite/rst/playbooks_variables.rst +++ b/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