From 58ff9cd7c84f95ce881ef61c1a4994b355f437a4 Mon Sep 17 00:00:00 2001 From: Christian Berendt Date: Sat, 3 May 2014 17:59:50 +0200 Subject: [PATCH] fixed typos found by RETF rules in RST files rules are avaialble at https://en.wikipedia.org/wiki/Wikipedia:AutoWikiBrowser/Typos --- docsite/rst/developing_modules.rst | 4 ++-- docsite/rst/developing_plugins.rst | 2 +- docsite/rst/faq.rst | 2 +- docsite/rst/glossary.rst | 2 +- docsite/rst/guide_rax.rst | 4 ++-- docsite/rst/guide_vagrant.rst | 2 +- docsite/rst/intro_adhoc.rst | 2 +- docsite/rst/intro_configuration.rst | 4 ++-- docsite/rst/intro_getting_started.rst | 2 +- docsite/rst/playbooks_delegation.rst | 2 +- docsite/rst/playbooks_loops.rst | 2 +- docsite/rst/playbooks_roles.rst | 2 +- 12 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docsite/rst/developing_modules.rst b/docsite/rst/developing_modules.rst index e8da717aed5..e4268eebe92 100644 --- a/docsite/rst/developing_modules.rst +++ b/docsite/rst/developing_modules.rst @@ -330,7 +330,7 @@ and guidelines: * Include a minimum of dependencies if possible. If there are dependencies, document them at the top of the module file, and have the module raise JSON error messages when the import fails. -* Modules must be self contained in one file to be auto-transferred by ansible. +* Modules must be self-contained in one file to be auto-transferred by ansible. * If packaging modules in an RPM, they only need to be installed on the control machine and should be dropped into /usr/share/ansible. This is entirely optional and up to you. @@ -338,7 +338,7 @@ and guidelines: * In the event of failure, a key of 'failed' should be included, along with a string explanation in 'msg'. Modules that raise tracebacks (stacktraces) are generally considered 'poor' modules, though Ansible can deal with these returns and will automatically convert anything unparseable into a failed result. If you are using the AnsibleModule common Python code, the 'failed' element will be included for you automatically when you call 'fail_json'. -* Return codes from modules are not actually not signficant, but continue on with 0=success and non-zero=failure for reasons of future proofing. +* Return codes from modules are not actually not significant, but continue on with 0=success and non-zero=failure for reasons of future proofing. * As results from many hosts will be aggregated at once, modules should return only relevant output. Returning the entire contents of a log file is generally bad form. diff --git a/docsite/rst/developing_plugins.rst b/docsite/rst/developing_plugins.rst index 5f6451494d1..d72e4aeffff 100644 --- a/docsite/rst/developing_plugins.rst +++ b/docsite/rst/developing_plugins.rst @@ -96,7 +96,7 @@ Development +++++++++++ More information will come later, though see the source of any of the existing callbacks and you should be able to get started quickly. -They should be reasonably self explanatory. +They should be reasonably self-explanatory. .. _distributing_plugins: diff --git a/docsite/rst/faq.rst b/docsite/rst/faq.rst index af9d4930600..6ddba819a48 100644 --- a/docsite/rst/faq.rst +++ b/docsite/rst/faq.rst @@ -81,7 +81,7 @@ What is the best way to make content reusable/redistributable? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you have not done so already, read all about "Roles" in the playbooks documentation. This helps you make playbook content -self contained, and works well with things like git submodules for sharing content with others. +self-contained, and works well with things like git submodules for sharing content with others. If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended. diff --git a/docsite/rst/glossary.rst b/docsite/rst/glossary.rst index 4db9e8d28b1..771c5922838 100644 --- a/docsite/rst/glossary.rst +++ b/docsite/rst/glossary.rst @@ -410,7 +410,7 @@ YAML ++++ Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define playbook configuration languages and also variable files. YAML is nice because it has a minimum of syntax and is very clean and easy for people to skim. It is a good data format for configuration files and humans, but also machine readable. Ansible's usage of YAML stemmed from Michael's first use of it inside of Cobbler around 2006. YAML is fairly popular in the dynamic language community and the format has libraries available -for serialization in many different languages (Python, Perl, Ruby, etc.). +for serialization in many languages (Python, Perl, Ruby, etc.). .. seealso:: diff --git a/docsite/rst/guide_rax.rst b/docsite/rst/guide_rax.rst index ae145c96f10..03c9b83007e 100644 --- a/docsite/rst/guide_rax.rst +++ b/docsite/rst/guide_rax.rst @@ -580,12 +580,12 @@ and less information has to be shared with remote hosts. Orchestration in the Rackspace Cloud ++++++++++++++++++++++++++++++++++++ -Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other pice of software in an environment. Complex deployments might have previously required manaul manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additioanl nodes contingent on the current number of running nodes, or the configuration of a clustered applicaiton dependent on the number of nodes with common metadata. One could automate the following scenarios, for example: +Ansible is a powerful orchestration tool, and rax modules allow you the opportunity to orchestrate complex tasks, deployments, and configurations. The key here is to automate provisioning of infrastructure, like any other pice of software in an environment. Complex deployments might have previously required manaul manipulation of load balancers, or manual provisioning of servers. Utilizing the rax modules included with Ansible, one can make the deployment of additioanl nodes contingent on the current number of running nodes, or the configuration of a clustered application dependent on the number of nodes with common metadata. One could automate the following scenarios, for example: * Servers that are removed from a Cloud Load Balancer one-by-one, updated, verified, and returned to the load balancer pool * Expansion of an already-online environment, where nodes are provisioned, bootstrapped, configured, and software installed * A procedure where app log files are uploaded to a central location, like Cloud Files, before a node is decommissioned -* Servers and load balancers that have DNS receords created and destroyed on creation and decomissioning, respectively +* Servers and load balancers that have DNS receords created and destroyed on creation and decommissioning, respectively diff --git a/docsite/rst/guide_vagrant.rst b/docsite/rst/guide_vagrant.rst index 9472b74dd2f..3a15617e302 100644 --- a/docsite/rst/guide_vagrant.rst +++ b/docsite/rst/guide_vagrant.rst @@ -13,7 +13,7 @@ provisioner for these virtual machines, and the two tools work together well. This guide will describe how to use Vagrant and Ansible together. -If you're not familar with Vagrant, you should visit `the documentation +If you're not familiar with Vagrant, you should visit `the documentation `_. This guide assumes that you already have Ansible installed and working. diff --git a/docsite/rst/intro_adhoc.rst b/docsite/rst/intro_adhoc.rst index f849a1021c0..787a7e76ee9 100644 --- a/docsite/rst/intro_adhoc.rst +++ b/docsite/rst/intro_adhoc.rst @@ -123,7 +123,7 @@ File Transfer Here's another use case for the `/usr/bin/ansible` command line. Ansible can SCP lots of files to multiple machines in parallel. -To transfer a file directly to many different servers:: +To transfer a file directly to many servers:: $ ansible atlanta -m copy -a "src=/etc/hosts dest=/tmp/hosts" diff --git a/docsite/rst/intro_configuration.rst b/docsite/rst/intro_configuration.rst index 6337e5cf3f3..0cf6e1e997c 100644 --- a/docsite/rst/intro_configuration.rst +++ b/docsite/rst/intro_configuration.rst @@ -22,7 +22,7 @@ Prior to 1.5 the order was:: * .ansible.cfg (in the home directory) * /etc/ansible/ansible.cfg -Ansible will process the above list and use the first file found. Settings in files are not merged together. +Ansible will process the above list and use the first file found. Settings in files are not merged. .. _getting_the_latest_configuration: @@ -228,7 +228,7 @@ hash_behaviour Ansible by default will override variables in specific precedence orders, as described in :doc:`playbooks_variables`. When a variable of higher precedence wins, it will replace the other value. -Some users prefer that variables that are hashes (aka 'dictionaries' in Python terms) are merged together. This setting is called 'merge'. This is not the default behavior and it does not affect variables whose values are scalars (integers, strings) or +Some users prefer that variables that are hashes (aka 'dictionaries' in Python terms) are merged. This setting is called 'merge'. This is not the default behavior and it does not affect variables whose values are scalars (integers, strings) or arrays. We generally recommend not using this setting unless you think you have an absolute need for it, and playbooks in the official examples repos do not use this setting:: diff --git a/docsite/rst/intro_getting_started.rst b/docsite/rst/intro_getting_started.rst index f5ab25e56f1..b44bec65651 100644 --- a/docsite/rst/intro_getting_started.rst +++ b/docsite/rst/intro_getting_started.rst @@ -109,7 +109,7 @@ Host Key Checking Ansible 1.2.1 and later have host key checking enabled by default. -If a host is reinstalled and has a different key in 'known_hosts', this will result in a error message until corrected. If a host is not initially in 'known_hosts' this will result in prompting for confirmation of the key, which results in a interactive experience if using Ansible, from say, cron. You might not want this. +If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a host is not initially in 'known_hosts' this will result in prompting for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this. If you wish to disable this behavior and understand the implications, you can do so by editing /etc/ansible/ansible.cfg or ~/.ansible.cfg:: diff --git a/docsite/rst/playbooks_delegation.rst b/docsite/rst/playbooks_delegation.rst index 921d7b080fd..e298ebd6904 100644 --- a/docsite/rst/playbooks_delegation.rst +++ b/docsite/rst/playbooks_delegation.rst @@ -125,7 +125,7 @@ Local Playbooks It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful for assuring the configuration of a system by putting a playbook on a crontab. This may also be used -to run a playbook inside a OS installer, such as an Anaconda kickstart. +to run a playbook inside an OS installer, such as an Anaconda kickstart. To run an entire playbook locally, just set the "hosts:" line to "hosts:127.0.0.1" and then run the playbook like so:: diff --git a/docsite/rst/playbooks_loops.rst b/docsite/rst/playbooks_loops.rst index 6d802f23a74..9b869cc4fd1 100644 --- a/docsite/rst/playbooks_loops.rst +++ b/docsite/rst/playbooks_loops.rst @@ -233,7 +233,7 @@ Sometimes you would want to retry a task until a certain condition is met. Here retries: 5 delay: 10 -The above example run the shell module recursively till the module's result has "all systems go" in it's stdout or the task has +The above example run the shell module recursively till the module's result has "all systems go" in its stdout or the task has been retried for 5 times with a delay of 10 seconds. The default value for "retries" is 3 and "delay" is 5. The task returns the results returned by the last task run. The results of individual retries can be viewed by -vv option. diff --git a/docsite/rst/playbooks_roles.rst b/docsite/rst/playbooks_roles.rst index ff23163cb04..364d89bd8d3 100644 --- a/docsite/rst/playbooks_roles.rst +++ b/docsite/rst/playbooks_roles.rst @@ -344,7 +344,7 @@ in taking high-quality modules into ansible core for inclusion, so this shouldn' An good example for this is if you worked at a company called AcmeWidgets, and wrote an internal module that helped configure your internal software, and you wanted other people in your organization to easily use this module -- but you didn't want to tell everyone how to configure their Ansible library path. -Alongside the 'tasks' and 'handlers' structure of of a role, add a directory named 'library'. In this 'library' directory, then include the module directly inside of it. +Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library'. In this 'library' directory, then include the module directly inside of it. Assuming you had this::