Fix spelling mistakes and reST typos in the doc

Change-Id: I61d9780f3f1937c6e8d326a670c40fb6a931dbce
This commit is contained in:
François Magimel 2018-12-08 19:12:26 +01:00
parent 7f3963efca
commit 46260a79ee
19 changed files with 66 additions and 60 deletions

View File

@ -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

View File

@ -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.

View File

@ -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.

View File

@ -39,10 +39,10 @@ Connection Info
firehose.openstack.org has 2 open ports for MQTT traffic:
* **1883** - The default MQTT port
* **80** - Uses websockets for the MQTT communication
* **8883** - The default SSL/TLS MQTT port
* **443** - The SSL/TLS websockets port
* **1883** - The default MQTT port
* **80** - Uses websockets for the MQTT communication
* **8883** - The default SSL/TLS MQTT 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.

View File

@ -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-merged
* change-restored
* comment-added
* draft-published
* hashtags-changed
* merge-failed
* patchset-created
* ref-updated
* reviewer-added
* topic-changed
* change-abandoned
* change-merged
* change-restored
* comment-added
* draft-published
* hashtags-changed
* merge-failed
* patchset-created
* ref-updated
* reviewer-added
* topic-changed
Payload
-------

View File

@ -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 there is a negative review and it hasn't been touched in 1 week, 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
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:
curl -i -H "Accept: application/json" --digest --user <<gerrit_user>>:<<http_pass>> -X GET https://review.openstack.org/a/accounts/{email}
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}
This will return a JSON dictionary, that will contain _account_id field.
2. Mark the account as inactive using gerrit ssh api, with:
ssh -p 29418 review.openstack.org gerrit set-account --inactive {account-id}
2. Mark the account as inactive using gerrit ssh api, with::
Alternatively you can use REST API, sending a DELETE for:
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 set-account --inactive {account-id}
3. Check if there are active gerrit ssh connections:
ssh -p 29418 review.openstack.org gerrit show-connections -n | grep {account-id}
Alternatively you can use REST API, sending a DELETE for::
And kill all of them with subsequent:
ssh -p 29418 review.openstack.org gerrit close-connection {connection-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::
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:
delete from change_messages where author_id={account-id} and change_id={change-id};
a change, you can delete them with following query::
delete from change_messages where author_id={account-id} and change_id={change-id};

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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```::

View File

@ -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

View File

@ -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,

View File

@ -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.