typo(*): fix spelling errors

Author: karthequian

docs/customizing_deis/cli-plugins.rst

@@ -27,7 +27,7 @@ Any flags after the command will also be sent to the plugin as an argument:
     $ deis accounts:list --debug
     $ deis-accounts list --debug
 
-But flags preceeding the command will not:
+But flags preceding the command will not:
 
 .. code-block:: console
 

docs/customizing_deis/router_settings.rst

@@ -41,8 +41,8 @@ setting                                      description
 /deis/router/affinityArg                     for requests with the indicated query string variable, hash its contents to perform session affinity (default: undefined)
 /deis/router/bodySize                        nginx body size setting (default: 1m)
 /deis/router/defaultTimeout                  default timeout value in seconds. Should be greater then the frontfacing load balancers timeout value (default: 1300)
-/deis/router/builder/timeout/connect         proxy_connect_timeout for deis-builder (default: 10000). Unit in miliseconds
-/deis/router/builder/timeout/tcp             proxy_timeout for deis-builder (default: 1200000). Unit in miliseconds
+/deis/router/builder/timeout/connect         proxy_connect_timeout for deis-builder (default: 10000). Unit in milliseconds
+/deis/router/builder/timeout/tcp             proxy_timeout for deis-builder (default: 1200000). Unit in milliseconds
 /deis/router/controller/timeout/connect      proxy_connect_timeout for deis-controller (default: 10m)
 /deis/router/controller/timeout/read         proxy_read_timeout for deis-controller (default: 20m)
 /deis/router/controller/timeout/send         proxy_send_timeout for deis-controller (default: 20m)

docs/installing_deis/baremetal.rst

@@ -50,7 +50,7 @@ Add the public key part for the SSH key generated in the first step to the user-
 Update $private_ipv4
 ^^^^^^^^^^^^^^^^^^^^
 
-`CoreOS`_ on bare metal doesn't detect the ``$private_ipv4`` reliably. Replace all occurences in
+`CoreOS`_ on bare metal doesn't detect the ``$private_ipv4`` reliably. Replace all occurrences in
 the user-data with the (private) IP address of the node.
 
 

docs/installing_deis/gce.rst

@@ -245,7 +245,7 @@ You will want to add two records as YAML objects. Here is an example edit for th
       ttl: 21600
       type: SOA
 
-And finaly execute the transaction.
+And finally execute the transaction.
 
 .. code-block:: console
 

docs/managing_deis/recovering-ceph-quorum.rst

@@ -8,7 +8,7 @@ Recovering Ceph quorum
 
 Ceph relies on `Paxos`_ to maintain a quorum among monitor services so that they agree on cluster state.
 In some cases Ceph can lose quorum, such as when hosts are added and removed from the cluster in
-quick successtion, without removing the old hosts from Ceph (see :ref:`add_remove_host`).
+quick succession, without removing the old hosts from Ceph (see :ref:`add_remove_host`).
 
 A telltale sign of quorum loss is when querying cluster health, ``ceph -s`` times out with monitor
 faults on every host in the cluster.

docs/managing_deis/upgrading-deis.rst

@@ -72,7 +72,7 @@ Graceful Upgrade
 ----------------
 
 Alternatively, an experimental feature exists to provide the ability to perform a graceful upgrade. This process is
-available for version 1.9.0 moving foward and is intended to facilitate upgrades within a major version (for example,
+available for version 1.9.0 moving forward and is intended to facilitate upgrades within a major version (for example,
 from 1.9.0 to 1.9.1 or 1.11.2). Upgrading between major versions is not supported (for example, from 1.9.0 to a
 future 2.0.0). Unlike the in-place process above, this process keeps the platform's routers and publishers up during
 the upgrade process. This means that there should only be a maximum of around 1-2 seconds of downtime while the
@@ -83,7 +83,7 @@ routers boot up. Many times, there will be no downtime at all.
     Your loadbalancer configuration is the determining factor for how much downtime will occur during a successful upgrade.
     If your loadbalancer is configured to quickly reactivate failed hosts to its pool of active hosts, its quite possible to
     achieve zero downtime upgrades. If your loadbalancer is configured to be more pessimistic, such as requiring multiple
-    successful healthchecks before reactiving a node, then the chance for downtime increases. You should review your
+    successful healthchecks before reactivating a node, then the chance for downtime increases. You should review your
     loadbalancers configuration to determine what to expect during the upgrade process.
 
 The process involves two ``deisctl`` subcommands, ``upgrade-prep`` and ``upgrade-takeover``, in coordination with a few other important commands.
@@ -107,7 +107,7 @@ to. Care should be taken not to overwrite the existing ``deisctl`` version.
 
 Now it is possible to prepare the cluster for the upgrade using the old ``deisctl`` binary. This command will shutdown
 and uninstall all components of the cluster except the router and publisher. This means your services should still be
-serving traffic afterwords, but nothing else in the cluster will be functional.
+serving traffic afterwards, but nothing else in the cluster will be functional.
 
 .. code-block:: console
 

docs/using_deis/deploy-application.rst

@@ -11,7 +11,7 @@ Supported Applications
 ----------------------
 Deis can deploy any application or service that can run inside a Docker container.  In order to be scaled horizontally, applications must follow Heroku's `twelve-factor methodology`_ and store state in external backing services.
 
-For example, if your application persists state to the local filesystem -- common with content management systems like Wordpress and Drupal -- it cannot be scaled horizonally using ``deis scale``.
+For example, if your application persists state to the local filesystem -- common with content management systems like Wordpress and Drupal -- it cannot be scaled horizontally using ``deis scale``.
 
 Fortunately, most modern applications feature a stateless application tier that can scale horizontally inside Deis.