Fix spelling mistakes and reST typos in the doc

Change-Id: I61d9780f3f1937c6e8d326a670c40fb6a931dbce

doc/source/afs.rst

@@ -43,7 +43,7 @@ OpenStack Cell
 
 AFS may be one of the most thoroughly documented systems in the world.
 There is plenty of very good information about how AFS works and the
-commands to use it.  This document will only cover the mininmum needed
+commands to use it.  This document will only cover the minimum needed
 to understand our deployment of it.
 
 OpenStack runs an AFS cell called ``openstack.org``.  There are three
@@ -283,7 +283,7 @@ Updating Settings
 
 If you wish to update the settings for an existing server, you can
 stop and remove the existing ``bnode`` (the collection of processes
-the overseeer is monitoring, created via ``bos create`` above) and
+the overseer is monitoring, created via ``bos create`` above) and
 recreate it.
 
 For example ::
@@ -360,7 +360,7 @@ point is composed of read-only volumes::
 In order to mount the ``mirror.foo`` volume under ``mirror`` we need
 to modify the read-write version of the ``mirror`` volume.  To make
 this easy, the read-write version of the cell root is mounted at
-``/afs/.openstack.org``.  Folllowing the same logic from earlier,
+``/afs/.openstack.org``.  Following the same logic from earlier,
 traversing to paths below that mount point will generally prefer
 read-write volumes.
 
@@ -465,7 +465,7 @@ our mirror update cron jobs, manually perform the first mirror update:
   a bug where it will not use renewed tokens and so token expiration
   during a vos release may cause a similar problem.
 
-* Once the initial sync and and ``vos release`` are complete, release
+* Once the initial sync and ``vos release`` are complete, release
   the lock file on mirror-update.
 
 Removing a mirror

doc/source/certificate_authority.rst

@@ -32,7 +32,7 @@ directories on bridge.openstack.org, having multiple CA services.
 Generating a CA certificate
 ---------------------------
 
-Below are the steps for create a new certificicate authority. Today we do this
+Below are the steps for create a new certificate authority. Today we do this
 on bridge.openstack.org.  Some important things to note, our pass phrase
 for our cakey.pem file is stored in our GPG password.txt file. Additionally, by
 default our cacert.pem file will only be valid for 3 years.
@@ -83,7 +83,7 @@ bridge.openstack.org.
     Write out database with 1 new entries
     Data Base Updated
 
-Generate a Cerfificate Request
+Generate a Certificate Request
 ------------------------------
 
 Each service that requires a SSL certificate will need to first request a
@@ -237,7 +237,7 @@ Installing the Certificates
 ---------------------------
 
 2 files will have been created, newcert.pem (public key) and newreq.pem (private
-key). Be sure to use caution while transporting these files, specifcially
+key). Be sure to use caution while transporting these files, specifically
 newreq.pem should be added into private hieradata for the specific server and
 then deleted from disk.
 

doc/source/contribute-cloud.rst

@@ -56,7 +56,7 @@ Each test instance requires:
 In a setting where our instances will be segregated, our usage
 patterns will cause us to be our own noisy neighbors at the worst
 times, so it would be best to plan for little or no overcommitment.
-In an unsegregrated public cloud setting, the distribution of our jobs
+In an unsegregated public cloud setting, the distribution of our jobs
 over a larger number of hypervisors will allow for more
 overcommitment.
 

doc/source/firehose.rst

@@ -39,10 +39,10 @@ Connection Info
 
 firehose.openstack.org has 2 open ports for MQTT traffic:
 
- * **1883** - The default MQTT port
+* **1883** - The default MQTT port
- * **80** - Uses websockets for the MQTT communication
+* **80** - Uses websockets for the MQTT communication
- * **8883** - The default SSL/TLS MQTT port
+* **8883** - The default SSL/TLS MQTT port
- * **443** - The SSL/TLS websockets port
+* **443** - The SSL/TLS websockets port
 
 
 Topics
@@ -120,7 +120,7 @@ to more specific.
 
 MQTT Protocol Example
 ---------------------
-Interacting with firehose on the unecrpyted MQTT port is normally pretty easy in
+Interacting with firehose on the unencrypted MQTT port is normally pretty easy in
 most language bindings. Here are some examples that will have the same behavior
 as the CLI example above and will subscribe to all topics on the firehose and
 print it to STDOUT.
@@ -275,7 +275,7 @@ Using SSL/TLS
 -------------
 If you would like to connect to the firehose using ssl to encrypt the events you
 recieve from MQTT you just need to connect with ssl enabled via either of the
-encypted ports. If you'd like to verify the server ssl certificate when
+encrypted ports. If you'd like to verify the server ssl certificate when
 connecting you'll need to provide a CA bundle to use as most MQTT clients do
 not know how to use the system trusted CA bundle like most http clients.
 

doc/source/firehose_schema.rst

@@ -34,17 +34,17 @@ The ``git namespace`` and ``repo name`` are pretty self explanatory and are just
 from the git repository the change in gerrit is for. The event is defined in the gerrit event stream. You can see the full reference for topics in the Gerrit
 docs for `Gerrit events`_. However, for simplicity the possible values are:
 
- * change-abandoned
+* change-abandoned
- * change-merged
+* change-merged
- * change-restored
+* change-restored
- * comment-added
+* comment-added
- * draft-published
+* draft-published
- * hashtags-changed
+* hashtags-changed
- * merge-failed
+* merge-failed
- * patchset-created
+* patchset-created
- * ref-updated
+* ref-updated
- * reviewer-added
+* reviewer-added
- * topic-changed
+* topic-changed
 
 Payload
 -------

doc/source/gerrit.rst

@@ -160,9 +160,9 @@ Auto Review Expiry
 Puppet automatically installs a daily cron job called ``expire-old-reviews``
 onto the Gerrit servers.  This script follows two rules:
 
- #. If the review hasn't been touched in 2 weeks, mark as abandoned.
+#. If the review hasn't been touched in 2 weeks, mark as abandoned.
- #. If there is a negative review and it hasn't been touched in 1 week, mark as
+#. If there is a negative review and it hasn't been touched in 1 week, mark as
-    abandoned.
+   abandoned.
 
 If your review gets touched by either of these rules, it is possible to
 unabandon a review on the Gerrit web interface.
@@ -669,30 +669,36 @@ must follow that steps:
    members can be found on: https://review.openstack.org/#/admin/groups/270,members
 
    That will give you the name and email of all members. Then you can get the matching
-   numerical account ID with the help of REST API:
+   numerical account ID with the help of REST API::
-   curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X GET https://review.openstack.org/a/accounts/{email}
+
+     curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X GET https://review.openstack.org/a/accounts/{email}
 
    This will return a JSON dictionary, that will contain _account_id field.
 
-2. Mark the account as inactive using gerrit ssh api, with:
+2. Mark the account as inactive using gerrit ssh api, with::
-   ssh -p 29418 review.openstack.org gerrit set-account --inactive {account-id}
 
-   Alternatively you can use REST API, sending a DELETE for:
+     ssh -p 29418 review.openstack.org gerrit set-account --inactive {account-id}
-   curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X DELETE https://review.openstack.org/a/accounts/{account-id}/active
 
-3. Check if there are active gerrit ssh connections:
+   Alternatively you can use REST API, sending a DELETE for::
-   ssh -p 29418 review.openstack.org gerrit show-connections -n | grep {account-id}
 
-   And kill all of them with subsequent:
+     curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X DELETE https://review.openstack.org/a/accounts/{account-id}/active
-   ssh -p 29418 review.openstack.org gerrit close-connection {connection-id}
+
+3. Check if there are active gerrit ssh connections::
+
+     ssh -p 29418 review.openstack.org gerrit show-connections -n | grep {account-id}
+
+   And kill all of them with subsequent::
+
+     ssh -p 29418 review.openstack.org gerrit close-connection {connection-id}
 
 4. You can check if the account is properly marked as inactive using REST API,
-   sending a GET for:
+   sending a GET for::
 
-   curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X GET https://review.openstack.org/a/accounts/{account-id}/active
+     curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X GET https://review.openstack.org/a/accounts/{account-id}/active
 
    A 200 return code means the account is active, and 204 means account inactive.
 
 4. In the case of a failing Third Party CI, if the account caused a loop of comments in
-   a change, you can delete them with following query:
+   a change, you can delete them with following query::
-   delete from change_messages where author_id={account-id} and change_id={change-id};
+
+     delete from change_messages where author_id={account-id} and change_id={change-id};

doc/source/github.rst

@@ -57,7 +57,7 @@ OpenStack Zuul App
 
 Zuul v3 is integrated with GitHub by way of a `GitHub App`_. This is done to
 enable OpenStack to test integration with external projects that use GitHub
-for development. Information on onfiguring projects to use the OpenStack Zuul
+for development. Information on configuring projects to use the OpenStack Zuul
 App can be found in the :ref:`zuul` page at :ref:`zuul_github_projects`.
 
 The OpenStack Zuul App is managed `OpenStack Zuul Settings Page`_ which is

doc/source/jeepyb.rst

@@ -76,7 +76,7 @@ option should have a value that is a path to the ``project.config``
 for that project.
 
 That is the high level view of how we can configure projects using the
-pupppet repository. To create an actual change that does all of this for
+puppet repository. To create an actual change that does all of this for
 a single project you will want to do the following:
 
 #. Add a ``gerrit/acls/organization/project-name.config`` file to the
@@ -103,7 +103,7 @@ a single project you will want to do the following:
 #. If there is an existing repo that is being replaced by this new
    project you can set the upstream value for the project. When an
    upstream is set, that upstream will be cloned and pushed into Gerrit
-   instead of an empty repository. eg::
+   instead of an empty repository. e.g.::
 
      - project: organization/project-name
        acl-config: /home/gerrit2/acls/organization/project-name.config
@@ -189,7 +189,7 @@ set of projects by reading a requirements.txt file, installing all
 listed dependencies into a virtualenv, inspecting the resulting
 installed package set, and then downloading all of the second-level
 (and further) dependencies.  Essentially, the mirror is built by
-introspection and contains the full set of depedencies needed whether
+introspection and contains the full set of dependencies needed whether
 they are explicitly listed or not.
 
 Admin tasks

doc/source/jjb.rst

@@ -218,7 +218,7 @@ arguments to and instantiates the job templates as real jobs. For example:
 Each project using templated jobs should have its own ``- project:`` section.
 Under this sections there should be a ``jobs:`` section with a list of job
 templates or job groups to be used by this project. Other values under the
-``- project:`` section define the arguments to the templates lised under
+``- project:`` section define the arguments to the templates listed under
 ``jobs:``. In this case we are giving the docs template ``name`` and ``node``
 values.
 

doc/source/kerberos.rst

@@ -42,7 +42,7 @@ Realm Creation
 On the first KDC host, the admin needs to run `krb5_newrealm` by hand. Then
 admin principals and host principles need to be set up.
 
-Set up host principals for slave propogation::
+Set up host principals for slave propagation::
 
    # execute kadmin.local then run these commands
    addprinc -randkey host/kdc01.openstack.org

doc/source/logstash.rst

@@ -206,7 +206,7 @@ loves it when you give it more memory. Currently we run a multi-node
 cluster on large VMs to give ElasticSearch both memory and disk space.
 Per index (Logstash creates one index per day) we have N+1 replica
 redundancy to distribute disk utilization and provide high availability.
-Each replica is broken into multiple shards providing inceased indexing
+Each replica is broken into multiple shards providing increased indexing
 and search throughput as each shard is essentially a valid mini index.
 
 To check on the cluster health, run this command on any es.* node::
@@ -279,7 +279,7 @@ can jumpstart the refining process with a simple query.
 This will show you all logs available from the patchset and build pair
 that failed. Chances are that this is still a significant number of
 logs and you will want to do more filtering. You can add more filters
-to the queriy using ``AND`` and ``OR`` and parentheses can be used to
+to the query using ``AND`` and ``OR`` and parentheses can be used to
 group sections of the query. Potential additions to the above query
 might be
 

doc/source/nodepool.rst

@@ -110,7 +110,7 @@ vhd-util
 ========
 
 Creating images for Rackspace requires a patched version of vhd-util to convert
-the images into the appropriate VHD format. A package is manaually managed
+the images into the appropriate VHD format. A package is manually managed
 at `ppa:openstack-ci-core/vhd-util` and is based on a git repo at
 https://github.com/emonty/vhd-util
 

doc/source/project.rst

@@ -39,7 +39,7 @@ We are most active on IRC, so please join the **#openstack-infra**
 channel on Freenode.
 
 Feel free to attend our `weekly IRC meeting
-<https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting>`_.
+<https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting>`_
 on Tuesdays at 19:00 UTC in #openstack-meeting.
 
 Check out our open bugs on `StoryBoard
@@ -144,7 +144,7 @@ Infrastructure Core Team
 Infrastructure Council
   The infrastructure council is the technical design body for the
   infrastructure project.  While individuals and groups are empowered
-  to execute the designs from the concil, major technical designs are
+  to execute the designs from the council, major technical designs are
   agreed upon as a group to ensure that our large set of projects are
   all working together to the same end.  The council need not delve
   too deeply into technical detail -- just enough so that development

doc/source/reprepro.rst

@@ -57,7 +57,7 @@ gathered from the upstream mirror.  Since the upstream mirror remains
 consistent, ``reprepro`` will always download a consistent set of
 files.  Then thanks to the release of the AFS mirror volume being
 atomic, we do not have any period where the repository package index
-doens't match the set of packages in the filesystem.
+doesn't match the set of packages in the filesystem.
 
 Since this does not require coordination with upstream, the same
 pattern is suitable across Ubuntu, Debian and other various apt

doc/source/running-your-own.rst

@@ -95,7 +95,7 @@ modules/openstack_project
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This tree defines the shape of servers (some of which are unique, some of which
-are scaled horizonally, thus the separation). To run your own infrastructure we
+are scaled horizontally, thus the separation). To run your own infrastructure we
 recommend you copy the entire tree, delete (or simply ignore) any servers you won't
 run, and replace hostnames and class names with yours throughout. Some templates can
 be used as-is by leaving their references to point within the openstack_project tree.

doc/source/storyboard.rst

@@ -72,7 +72,7 @@ Adding an Admin to StoryBoard
 -----------------------------
 
 StoryBoard administrators are handled from a single configuration file, and
-are identified by OpenID. To add a new administator, simply add their
+are identified by OpenID. To add a new administrator, simply add their
 Launchpad OpenID string and email as follows:
 
 ``:config:`gerrit/projects.yaml```::

doc/source/survey.rst

@@ -51,7 +51,7 @@ Elevate your account to Superadmin via mysqlclient:
 value is in the users table for your OpenID-autocreated account)
 
 Refresh your browser. When logged in via the web-ui you should now have
-superadmin priviledges allowing you to set the following values:
+superadmin privileges allowing you to set the following values:
 
 Configuration > Global Settings > Email Settings
 

doc/source/unofficial_project_hosting.rst

@@ -5,7 +5,7 @@
 Unofficial Project Hosting
 ##########################
 
-Unoffocial project hosting is the way that OpenStack related projects can
+Unofficial project hosting is the way that OpenStack related projects can
 consume and make use of the OpenStack project infrastructure. This
 includes Gerrit code review, Zuul continuous integration, GitHub
 repository mirroring, and various small things like IRC bots, pypi uploads,

doc/source/zuulv3.rst

@@ -177,7 +177,7 @@ Executors
 
 The Zuul Executors are a horizontally scalable set of servers named
 ze*.openstack.org. They perform git merging operations for the scheduler
-and execute Ansible playboks to actually run jobs.
+and execute Ansible playbooks to actually run jobs.
 
 Our jobs are configured to upload as much information as possible along with
 their logs, but if there is an error which can not be diagnosed in that
@@ -213,7 +213,7 @@ between OpenStack projects and those ecosystem projects, we can add the
 OpenStack Zuul GitHub app to those projects, then configure them in Zuul.
 
 In order to add the GitHub app to a project, an admin on that project should
-nagivate to the `OpenStack Zuul`_ app in the GitHub UI. From there they can
+navigate to the `OpenStack Zuul`_ app in the GitHub UI. From there they can
 click "Install", then choose the project or organization they want to install
 the App on.