diff --git a/doc/source/afs.rst b/doc/source/afs.rst index 0504180281..b6378541f9 100644 --- a/doc/source/afs.rst +++ b/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 diff --git a/doc/source/certificate_authority.rst b/doc/source/certificate_authority.rst index 92a3d53f9d..0ee20b6ab4 100644 --- a/doc/source/certificate_authority.rst +++ b/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. diff --git a/doc/source/contribute-cloud.rst b/doc/source/contribute-cloud.rst index 00bb8a189c..74781d5ddb 100644 --- a/doc/source/contribute-cloud.rst +++ b/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. diff --git a/doc/source/firehose.rst b/doc/source/firehose.rst index 61085f15ec..d705907334 100644 --- a/doc/source/firehose.rst +++ b/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 - * **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. diff --git a/doc/source/firehose_schema.rst b/doc/source/firehose_schema.rst index 5ef835504b..3d05470d93 100644 --- a/doc/source/firehose_schema.rst +++ b/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-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 ------- diff --git a/doc/source/gerrit.rst b/doc/source/gerrit.rst index fc06fbae40..d93e40bd19 100644 --- a/doc/source/gerrit.rst +++ b/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 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 <>:<> -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 <>:<> -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 <>:<> -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 <>:<> -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 <>:<> -X GET https://review.openstack.org/a/accounts/{account-id}/active + curl -i -H "Accept: application/json" --digest --user <>:<> -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}; diff --git a/doc/source/github.rst b/doc/source/github.rst index 2e4c253df2..e7fceba6ab 100644 --- a/doc/source/github.rst +++ b/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 diff --git a/doc/source/jeepyb.rst b/doc/source/jeepyb.rst index 8785f657ea..f1143e7682 100644 --- a/doc/source/jeepyb.rst +++ b/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 diff --git a/doc/source/jjb.rst b/doc/source/jjb.rst index 6ecada814b..69632c4110 100644 --- a/doc/source/jjb.rst +++ b/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. diff --git a/doc/source/kerberos.rst b/doc/source/kerberos.rst index e33effa668..3270381e9a 100644 --- a/doc/source/kerberos.rst +++ b/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 diff --git a/doc/source/logstash.rst b/doc/source/logstash.rst index 04f222195e..fc007758c7 100644 --- a/doc/source/logstash.rst +++ b/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 diff --git a/doc/source/nodepool.rst b/doc/source/nodepool.rst index 0ad46fad6c..4d1777a006 100644 --- a/doc/source/nodepool.rst +++ b/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 diff --git a/doc/source/project.rst b/doc/source/project.rst index 513fa52202..d6c675f48a 100644 --- a/doc/source/project.rst +++ b/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 -`_. +`_ 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 diff --git a/doc/source/reprepro.rst b/doc/source/reprepro.rst index 8d2d92a8a9..483b3cf124 100644 --- a/doc/source/reprepro.rst +++ b/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 diff --git a/doc/source/running-your-own.rst b/doc/source/running-your-own.rst index 260293f74d..fc48794535 100644 --- a/doc/source/running-your-own.rst +++ b/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. diff --git a/doc/source/storyboard.rst b/doc/source/storyboard.rst index b9d6c8feca..41b4ab4a26 100644 --- a/doc/source/storyboard.rst +++ b/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```:: diff --git a/doc/source/survey.rst b/doc/source/survey.rst index d23f046dd9..3d7a7ffb77 100644 --- a/doc/source/survey.rst +++ b/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 diff --git a/doc/source/unofficial_project_hosting.rst b/doc/source/unofficial_project_hosting.rst index 79f194195c..1d31bc8a04 100644 --- a/doc/source/unofficial_project_hosting.rst +++ b/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, diff --git a/doc/source/zuulv3.rst b/doc/source/zuulv3.rst index 19aceceffa..0f55343ac8 100644 --- a/doc/source/zuulv3.rst +++ b/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.