Merge pull request #12434 from hulu/copyediting

docs copyediting

doc/topics/cloud/cloud.rst

@@ -234,7 +234,7 @@ excellent example is in the Azure driver.
 
 The destroy() Function
 ----------------------
-This function irreversably destroys a virtual machine on the cloud provider.
+This function irreversibly destroys a virtual machine on the cloud provider.
 Before doing so, it should fire an event on the Salt event bus. The tag for this
 event is ``salt/cloud/<vm name>/destroying``. Once the virtual machine has been
 destroyed, another event is fired. The tag for that event is

doc/topics/cloud/features.rst

@@ -10,14 +10,14 @@ make sense for a particular cloud provider (Saltify, for instance).
 
 This matrix shows which features are available in which cloud providers, as far
 as Salt Cloud is concerned. This is not a comprehensive list of all features
-available in all cloud providers, and shoult not be used to make business
+available in all cloud providers, and should not be used to make business
 decisions concerning choosing a cloud provider. In most cases, adding support
 for a feature to Salt Cloud requires only a little effort.
 
 Legacy Drivers
 ==============
 Both AWS and Rackspace are listed as "Legacy". This is because those drivers
-have been replaced by other drivers, which are generally the prerferred method
+have been replaced by other drivers, which are generally the preferred method
 for working with those providers.
 
 The EC2 driver should be used instead of the AWS driver, when possible. The

doc/topics/cloud/gce.rst

@@ -329,7 +329,7 @@ a function or an action.
 Create snapshot
 ---------------
 You can take a snapshot of an existing disk's content. The snapshot can then
-in turn be used to create other persistend disks. Note that to prevent data
+in turn be used to create other persistent disks. Note that to prevent data
 corruption, it is strongly suggested that you unmount the disk prior to
 taking a snapshot. You must name the snapshot and provide the name of the
 disk.
@@ -461,7 +461,7 @@ Load-balancer
 -------------
 When creating a new load-balancer, it requires a name, region, port range,
 and list of members. There are other optional parameters for protocol,
-and list of healtch checks. Deleting or showing details about the LB only
+and list of health checks. Deleting or showing details about the LB only
 requires the name.
 
 .. code-block:: bash

doc/topics/cloud/hpcloud.rst

@@ -140,7 +140,7 @@ it can be verified with Salt:
 SSH to the instance
 ===================
 
-Additionally, the instance can be acessed via SSH using the floating IP assigned to it
+Additionally, the instance can be accessed via SSH using the floating IP assigned to it
 
 .. code-block:: bash
 
@@ -149,7 +149,7 @@ Additionally, the instance can be acessed via SSH using the floating IP assigned
 Using a private IP
 ==================
 
-Alternatively, in the cloud profile, using the private IP to log into the instance to set up the minion is another option, paerticularly if salt-cloud is running within the cloud on an instance that is on the same network with all the other instances (minions)
+Alternatively, in the cloud profile, using the private IP to log into the instance to set up the minion is another option, particularly if salt-cloud is running within the cloud on an instance that is on the same network with all the other instances (minions)
 
 The example below is a modified version of the previous example. Note the use of ``ssh_interface``:
 

doc/topics/cloud/rackspace.rst

@@ -73,7 +73,7 @@ Rackspace currently has six compute regions which may be used:
     IAD -> Northern Virginia
     HKG -> Hong Kong
 
-Note: Currently the LON region is only avaiable with a UK account, and UK accounts cannot access other regions
+Note: Currently the LON region is only available with a UK account, and UK accounts cannot access other regions
 
 Authentication
 ==============

doc/topics/cloud/salt.rst

@@ -223,7 +223,7 @@ State Module
 A subset of the execution module is available through the ``cloud`` state
 module. Not all functions are currently included, because there is currently
 insufficient code for them to perform statefully. For example, a command to
-create an istance may be issued with a series of options, but those options
+create an instance may be issued with a series of options, but those options
 cannot currently be statefully managed. Additional states to manage these
 options will be released at a later time.
 

doc/topics/cloud/softlayer.rst

@@ -7,7 +7,7 @@ SoftLayer is a public cloud provider, and baremetal hardware hosting provider.
 Dependencies
 ============
 The SoftLayer driver for Salt Cloud requires the softlayer package, which is
-available at PyPi:
+available at PyPI:
 
 https://pypi.python.org/pypi/SoftLayer
 

doc/topics/development/dunder_dictionaries.rst

@@ -22,7 +22,7 @@ configuration file for the master or minion.
 .. note::
 
     In many places in salt, instead of pulling raw data from the __opts__
-    dict, configuration data should be pulled from the salt `get` frunctions
+    dict, configuration data should be pulled from the salt `get` functions
     such as config.get, aka - __salt__['config.get']('foo:bar')
     The `get` functions also allow for dict traversal via the *:* delimiter.
     Consider using get functions whenever using __opts__ or __pillar__ and

doc/topics/eauth/index.rst

@@ -126,7 +126,7 @@ the ``{{ username }}`` value for the username when querying LDAP.
     auth.ldap.filter: uid={{ username }}
 
 If group support for LDAP is desired, one can specify an OU that contains group
-data. This is pre-pendeed to the basedn to create a search path
+data. This is prepended to the basedn to create a search path
 
 .. code-block:: yaml
 

doc/topics/installation/debian.rst

@@ -4,7 +4,7 @@ Debian Installation
 
 Currently the latest packages for Debian Old Stable, Stable and
 Unstable (Squeeze, Wheezy and Sid) are published in our
-(saltstack.com) debian repository.
+(saltstack.com) Debian repository.
 
 Configure Apt
 -------------
@@ -13,7 +13,7 @@ Configure Apt
 Squeeze (Old Stable)
 ~~~~~~~~~~~~~~~~~~~~
 
-For squeeze, you will need to enable the debian backports repository
+For squeeze, you will need to enable the Debian backports repository
 as well as the debian.saltstack.com repository. To do so, add the
 following to ``/etc/apt/sources.list`` or a file in
 ``/etc/apt/sources.list.d``::
@@ -95,7 +95,7 @@ Notes
 -----
 
 1. These packages will be backported from the packages intended to be
-uploaded into debian unstable. This means that the packages will be
+uploaded into Debian unstable. This means that the packages will be
 built for unstable first and then backported over the next day or so.
 
 2. These packages will be tracking the released versions of salt
@@ -104,7 +104,7 @@ is what you desire, then either pinning or manual installation may be
 more appropriate for you.
 
 3. The version numbering and backporting process should provide clean
-upgrade paths between debian versions.
+upgrade paths between Debian versions.
 
 If you have any questions regarding these, please email the mailing
-list or look for joehh on irc.
+list or look for joehh on IRC.

doc/topics/jobs/schedule.rst

@@ -72,7 +72,7 @@ Scheduler With Returner
 =======================
 
 The scheduler is also useful for tasks like gathering monitoring data about
-a minion, this schedule option will gather status data and send it to a mysql
+a minion, this schedule option will gather status data and send it to a MySQL
 returner database:
 
 .. code-block:: yaml

doc/topics/pillar/index.rst

@@ -217,7 +217,7 @@ This makes handling nested structures much easier.
     It should be noted that within templating, the ``pillar`` variable is just
     a dictionary.  This means that calling ``pillar.get()`` inside of a
     template will just use the default dictionary ``.get()`` function which
-    does not include the extra ``:`` delimeter functionality.  It must be
+    does not include the extra ``:`` delimiter functionality.  It must be
     called using the above syntax (``salt['pillar.get']('foo:bar:baz',
     'qux')``) to get the salt function, instead of the default dictionary
     behavior.

doc/topics/reactor/index.rst

@@ -197,7 +197,7 @@ the :strong:`cmd_async` method inside of the :strong:`LocalClient` class. This
 means that the arguments passed are being passed to the :strong:`cmd_async`
 method, not the remote method. A field starts with :strong:`cmd` to use the
 :strong:`LocalClient` subsystem. The result is, to execute a remote command, 
-a reactor fomular would look like this:
+a reactor formula would look like this:
 
 .. code-block:: yaml
 
@@ -305,7 +305,7 @@ will come online at random and need to have keys automatically accepted. We'll
 also add that we don't want all servers being automatically accepted. For this
 example, we'll assume that all hosts that have an id that starts with 'ink'
 will be automatically accepted and have state.highstate executed. On top of
-thise, we're going to add that a host coming up that was replaced (meaning a new
+this, we're going to add that a host coming up that was replaced (meaning a new
 key) will also be accepted.
 
 Our master configuration will be rather simple. All minions that attempte to

doc/topics/ssh/roster.rst

@@ -2,7 +2,7 @@
 Salt Rosters
 ============
 
-Salt rosters are plugable systems added in Salt 0.17.0 to facilitate the
+Salt rosters are pluggable systems added in Salt 0.17.0 to facilitate the
 ``salt-ssh`` system.
 The roster system was created because ``salt-ssh`` needs a means to
 identify which systems need to be targeted for execution.

doc/topics/targeting/grains.rst

@@ -174,7 +174,7 @@ change, consider using :doc:`Pillar <../pillar/index>` instead.
 Precedence
 ==========
 
-Core grains can be overriden by custom grains. As there are several ways of
+Core grains can be overridden by custom grains. As there are several ways of
 defining custom grains, there is an order of precedence which should be kept in
 mind when defining them. The order of evaluation is as follows:
 

doc/topics/troubleshooting/master.rst

@@ -196,7 +196,7 @@ Passing the -c Option to Salt Returns a Permissions Error
 =========================================================
 
 Using the ``-c`` option with the Salt command modifies the configuration
-directory. When the configuratio file is read it will still base data off of
+directory. When the configuration file is read it will still base data off of
 the ``root_dir`` setting. This can result in unintended behavior if you are
 expecting files such as ``/etc/salt/pki`` to be pulled from the location
 specified with ``-c``. Modify the ``root_dir`` setting to address this

doc/topics/tutorials/esky.rst

@@ -21,7 +21,7 @@ This process does work on Windows. Follow the directions at
 installing Salt in Windows. Only the 32-bit Python and dependencies have been
 tested, but they have been tested on 64-bit Windows.
 
-You will need to install ``esky`` and ``bbfreeze`` from Pypi in order to enable
+You will need to install ``esky`` and ``bbfreeze`` from PyPI in order to enable
 the ``bdist_esky`` command in ``setup.py``.
 
 Building and Freezing
@@ -36,7 +36,7 @@ versioned ``salt-VERSION.zip`` in ``dist/`` if everything went smoothly.
 Windows
 -------
 You will need to add ``C:\Python27\lib\site-packages\zmq`` to your PATH
-variable. This helps bbfreeze find the zmq dll so it can pack it up.
+variable. This helps bbfreeze find the zmq DLL so it can pack it up.
 
 Using the Frozen Build
 ======================

doc/topics/tutorials/halite.rst

@@ -35,7 +35,7 @@ On CentOS, RHEL, or Fedora:
 Installing Halite Using pip
 ===========================
 
-To begin the installation of Halite from PyPi, you'll need to install pip. The
+To begin the installation of Halite from PyPI, you'll need to install pip. The
 Salt package, as well as the bootstrap, do not install pip by default.
 
 On CentOS, RHEL, or Fedora:

doc/topics/tutorials/pillar.rst

@@ -153,7 +153,7 @@ state, you can use Jinja:
 This approach allows for users to be safely defined in a pillar and then the
 user data is applied in an sls file.
 
-Paramaterizing States With Pillar
+Parameterizing States With Pillar
 =================================
 
 Pillar data can be accessed in state files to customise behaviour for each 

doc/topics/tutorials/quickstart.rst

@@ -21,7 +21,7 @@ commands with ``salt``, the ``salt-call`` command is used instead:
 Bootstrap Salt Minion
 =====================
 
-The `salt-bootstrap`_ script makes boostrapping a server with Salt simple
+The `salt-bootstrap`_ script makes bootstrapping a server with Salt simple
 for any OS with a Bourne shell:
 
 .. code-block:: bash

doc/topics/tutorials/starting_states.rst

@@ -143,7 +143,7 @@ the Apache ID, the user and group will be the Apache user and group. The
 the group, and that the group will be made only after the Apache package is
 installed.
 
-Next,the ``require`` statement under service was changed to watch, and is
+Next, the ``require`` statement under service was changed to watch, and is
 now watching 3 states instead of just one. The watch statement does the same
 thing as require, making sure that the other states run before running the
 state with a watch, but it adds an extra component. The ``watch`` statement

doc/topics/tutorials/writing_tests.rst

@@ -15,7 +15,7 @@ Getting Set Up For Tests
 ========================
 
 To walk through adding an integration test, start by getting the latest
-development code and the test system from github:
+development code and the test system from GitHub:
 
 .. note::
 

doc/topics/windows/windows-package-manager.rst

@@ -31,7 +31,7 @@ The install state/module function of the windows package manager works
 roughly as follows:
 
 1. Execute ``pkg.list_pkgs`` and store the result
-2. Check if any action needs to be taken. (ie compare required package
+2. Check if any action needs to be taken. (i.e. compare required package
    and version against ``pkg.list_pkgs`` results)
 3. If so, run the installer command.
 4. Execute ``pkg.list_pkgs`` and compare to the result stored from
@@ -89,7 +89,7 @@ The package definition file should look similar to this example for Firefox:
 More examples can be found here: https://github.com/saltstack/salt-winrepo
 
 The version number and ``full_name`` need to match the output from ``pkg.list_pkgs``
-so that the status can be verfied when running highstate.
+so that the status can be verified when running highstate.
 Note: It is still possible to successfully install packages using ``pkg.install``
 even if they don't match which can make this hard to troubleshoot.
 

doc/topics/yaml/index.rst

@@ -3,7 +3,7 @@ Understanding YAML
 
 The default renderer for SLS files is the YAML renderer. YAML is a
 markup language with many powerful features. However, Salt uses
-a small subset of YAML that maps over very commonly used data stuctures,
+a small subset of YAML that maps over very commonly used data structures,
 like lists and dictionaries. It is the job of the YAML renderer to take
 the YAML data structure and compile it into a Python data structure for
 use by Salt.