Merge pull request #13025 from MTecknology/develop

minor doc touchups

doc/topics/installation/index.rst

@@ -84,10 +84,10 @@ Optional Dependencies
 Upgrading Salt
 --------------
 
-When upgrading Salt, the master(s) should always be upgraded first.  Backwards
+When upgrading Salt, the master(s) should always be upgraded first.  Backward
 compatibility for minions running newer versions of salt than their masters is
 not guaranteed.
 
-Whenever possible, backwards compatibility between new masters
-and old minions will be preserved.  Generally, the only exception to this
-policy is in case of a security vulnerability.
+Whenever possible, backward compatibility between new masters and old minions
+will be preserved.  Generally, the only exception to this policy is in case of
+a security vulnerability.

doc/topics/tutorials/cloud_controller.rst

@@ -9,11 +9,11 @@ referred to as :strong:`Salt Virt`.
 The Salt Virt system already exists and is installed within Salt itself, this
 means that beyond setting up Salt no additional salt code needs to be deployed.
 
-The main goal of Salt Virt is the facilitate a very fast and simple cloud. A
+The main goal of Salt Virt is to facilitate a very fast and simple cloud. A
 cloud that can scale and a fully featured cloud. Salt Virt comes with the
 ability to set up and manage complex virtual machine networking, powerful
-image and disk management, as well as virtual machine migration, migration
-with and without shared storage.
+image and disk management, as well as virtual machine migration with and without
+shared storage.
 
 This means that Salt Virt can be used to create a cloud from a blade center
 and a SAN, but can also create a cloud out of a swarm of Linux Desktops
@@ -30,7 +30,7 @@ installed and setting up the hypervisor network interfaces.
 Installing Hypervisor Software
 ------------------------------
 
-Salt Virt is made to be hypervisor agnostic, but currently the only fully
+Salt Virt is made to be hypervisor agnostic but currently the only fully
 implemented hypervisor is KVM via libvirt.
 
 The required software for a hypervisor is libvirt and kvm. For advanced 
@@ -113,14 +113,14 @@ Virtual Machine Network Setup
 -----------------------------
 
 Salt Virt comes with a system to model the network interfaces used by the
-deployed virtual machines, by default a single interface is created for the
+deployed virtual machines; by default a single interface is created for the
 deployed virtual machine and is bridged to ``br0``. To get going with the
-default networking setup ensure that the bridge interface named ``br0`` exists
+default networking setup, ensure that the bridge interface named ``br0`` exists
 on the hypervisor and is bridged to an active network device.
 
 .. note::
 
-    To use more advanced networking in Salt Virt read the `Salt Virt
+    To use more advanced networking in Salt Virt, read the `Salt Virt
     Networking` document:
 
     :doc:`Salt Virt Networking </topics/virt/nic>`
@@ -162,9 +162,9 @@ Virtual Machine generation applications are available for many platforms:
 vm-builder:
   https://wiki.debian.org/VMBuilder
 
-Once virtual machines images are available the easiest way to make them available
-to Salt Virt is to place them in the Salt file server. Just copy an image into
-``/srv/salt`` and it can now be used by Salt Virt.
+Once virtual machine images are available, the easiest way to make them
+available to Salt Virt is to place them in the Salt file server. Just copy an
+image into ``/srv/salt`` and it can now be used by Salt Virt.
 
 For purposes of this demo, the file name ``centos.img`` will be used.
 

doc/topics/tutorials/pillar.rst

@@ -14,7 +14,7 @@ only to the relevant minion.
 .. note::
 
     Grains and Pillar are sometimes confused, just remember that Grains
-    is data about a minion which is stored or generated from the minion.
+    are data about a minion which is stored or generated from the minion.
     This is why information like the OS and CPU type are found in Grains.
     Pillar is information about a minion or many minions stored or generated
     on the Salt Master.
@@ -38,7 +38,7 @@ Arbitrary Data:
     key/value store can be defined making it easy to iterate over a group
     of values in sls formulas
 
-Pillar is therefore one of the most important systems when using Salt, this
+Pillar is therefore one of the most important systems when using Salt. This
 walkthrough is designed to get a simple Pillar up and running in a few minutes
 and then to dive into the capabilities of Pillar and where the data is
 available.

doc/topics/tutorials/quickstart.rst

@@ -6,7 +6,7 @@ Salt Masterless Quickstart
 .. _`salty-vagrant`: https://github.com/saltstack/salty-vagrant
 .. _`salt-bootstrap`: https://github.com/saltstack/salt-bootstrap
 
-Running a master-less salt-minion lets you use Salt's configuration management
+Running a masterless salt-minion lets you use Salt's configuration management
 for a single machine without calling out to a Salt master on another machine.
 
 Since the Salt minion contains such extensive functionality it can be useful

doc/topics/tutorials/states_pt5.rst

@@ -28,8 +28,8 @@ Orchestration can be accomplished in two distinct ways:
 The OverState System
 --------------------
 
-Often servers need to be set up and configured in a specific order, and systems
-should only be set up if systems earlier in the sequence has been set up
+Often, servers need to be set up and configured in a specific order, and systems
+should only be set up if systems earlier in the sequence have been set up
 without any issues.
 
 The OverState system can be used to orchestrate deployment in a smooth and
@@ -44,7 +44,7 @@ in the root of a Salt fileserver environment.
 The overstate.sls configures an unordered list of stages, each stage defines
 the minions on which to execute the state, and can define what sls files to
 run, execute a :mod:`state.highstate <salt.modules.state.highstate>`, or
-execute a function. Here's a sample overstate.sls:
+execute a function. Here's a sample ``overstate.sls``:
 
 .. code-block:: yaml
 

doc/topics/tutorials/walkthrough_macosx.rst

@@ -92,7 +92,7 @@ have to do it all over again. It also lets you *uninstall* things easily.
 .. note::
 
     Brew is a Ruby program (Ruby is installed by default with your Mac). Brew
-    downloads, compile and links software. The linking phase is when compiled
+    downloads, compiles and links software. The linking phase is when compiled
     software is deployed on your machine. It may conflict with manually
     installed software, especially in the /usr/local directory. It's ok,
     remove the manually installed version then refresh the link by typing
@@ -120,8 +120,8 @@ Or just type
     ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
 
 
-Now type the following commands in your terminal (you may want to type brew
-doctor after each to make sure everything's fine):
+Now type the following commands in your terminal (you may want to type ``brew
+doctor`` after each to make sure everything's fine):
 
 .. code-block:: bash
 
@@ -137,7 +137,7 @@ doctor after each to make sure everything's fine):
 Install Salt
 ------------
 
-you should now have everything ready to launch this command:
+You should now have everything ready to launch this command:
 
 .. code-block:: bash
 
@@ -219,7 +219,7 @@ Install Vagrant
 ---------------
 
 Go get it here: http://downloads.vagrantup.com/ and choose the latest version
-(1.3.5 at time of writing), then the .dmg file. double-click to install it.
+(1.3.5 at time of writing), then the .dmg file. Double-click to install it.
 Make sure the ``vagrant`` command is found when run in the terminal. Type
 ``vagrant``. It should display a list of commands.
 
@@ -298,14 +298,14 @@ to the terminal:
 
 The VM should respond to your ping request.
 
-Now log inside the VM in ssh using Vagrant again:
+Now log into the VM in ssh using Vagrant again:
 
 .. code-block:: bash
 
     vagrant ssh
 
-You should see the shell prompt changing to something similar to
-``vagrant@precise64:~$`` meaning you're inside the VM. From there enter the
+You should see the shell prompt change to something similar to
+``vagrant@precise64:~$`` meaning you're inside the VM. From there, enter the
 following:
 
 .. code-block:: bash
@@ -337,9 +337,9 @@ following lines, giving the ID for this minion, and the IP of the master:
     file_client: remote
 
 Minions authenticate with the master using keys. Keys are generated
-automatically if you don't provide one, and you can accept them later on. But
-this requires you to accept the minion key every time you destroy and recreate
-a minion (which could be quite often). A better way is to create those keys in
+automatically if you don't provide one and can accept them later on. However,
+this requires accepting the minion key every time the minion is destroyed or
+created (which could be quite often). A better way is to create those keys in
 advance, feed them to the minion, and authorize them once.
 
 Preseed minion keys
@@ -352,7 +352,7 @@ From the minion folder on your Mac run:
     sudo salt-key --gen-keys=minion1
 
 This should create two files: minion1.pem, and minion1.pub.
-Since those files have been created by sudo, but will be used by vagrant,
+Since those files have been created using sudo, but will be used by vagrant,
 you need to change ownership:
 
 .. code-block:: bash

doc/topics/tutorials/writing_tests.rst

@@ -20,8 +20,8 @@ development code and the test system from GitHub:
 .. note::
 
     The develop branch often has failing tests and should always be considered
-    a staging area. For a checkout that tests should be running perfectly on
-    please checkout from a specific release tag.
+    a staging area. For a checkout that tests should be running perfectly on,
+    please check out a specific release tag (such as v2014.1.4).
 
 .. code-block:: bash
 
@@ -33,7 +33,7 @@ Now that a fresh checkout is available run the test suite
 Destructive vs Non-destructive
 ==============================
 
-Since Salt is used to change the settings and behavior of systems often the
+Since Salt is used to change the settings and behavior of systems, often, the
 best approach to run tests is to make actual changes to an underlying system.
 This is where the concept of destructive integration tests comes into play.
 Tests can be written to alter the system they are running on. This capability