Fix spelling mistakes and reST typos in the doc
Change-Id: I61d9780f3f1937c6e8d326a670c40fb6a931dbce
This commit is contained in:
François Magimel
parent
7f3963efca
commit
46260a79ee
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
-------
|
||||
|
||||
@ -160,8 +160,8 @@ 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
|
||||
#. 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
|
||||
@ -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}
|
||||
|
||||
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:
|
||||
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
|
||||
|
||||
3. Check if there are active gerrit ssh connections:
|
||||
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:
|
||||
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
|
||||
|
||||
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};
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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```::
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user