Fix typos in oslo-specs

TrivialFix

Change-Id: Id4166c4e5941061a65cf7aafaa748a60286caadd

specs/juno/rootwrap-daemon-mode.rst

@@ -21,7 +21,7 @@ Proposed change
 
 I propose creating a new mode of operation for rootwrap - daemon mode. In this
 mode rootwrap would start, read config file and wait for commands to be run
-with root priviledges. Each service's process will have its own rootwrap daemon
+with root privileges. Each service's process will have its own rootwrap daemon
 process.
 
 Daemon starting
@@ -198,7 +198,7 @@ etherpad [#neu_eth]_:
   necessary work for one request, for example. But these scripts will either
   become very complex (say rewriting parts of Neutron agents in shell) or there
   will be too many of them. Either way defeats the purpose of sudo and rootwrap
-  - to minimize amount and complexity of code running with root priviledges.
+  - to minimize amount and complexity of code running with root privileges.
 
 * Per-host daemon process
 

specs/kilo/oslo-middleware-healthcheck.rst

@@ -36,9 +36,9 @@ The idea is to create a wsgi middleware that all openstack components can use:
 The middleware will return "200 OK" if everything is OK,
 or "503 <REASON>" if not with the reason of why this API should not be used.
 
-"backends" will the name of a stevedore extentions in the namespace "oslo.middleware.healthcheck".
+"backends" will the name of a stevedore extensions in the namespace "oslo.middleware.healthcheck".
 
-oslo.middleware will also provide a base class for these extentions:
+oslo.middleware will also provide a base class for these extensions:
 
 .. code-block:: python
 
@@ -71,7 +71,7 @@ And so the setup.cfg will have entry_point like that:
       disable_by_file = oslo.middleware.healthcheck:DisableByFileHealthcheck
 
 
-The 'DisableByFileHealthcheck' extention will return if the 'disable_by_file_path'
+The 'DisableByFileHealthcheck' extension will return if the 'disable_by_file_path'
 file is missing:
 
 .. code-block:: python
@@ -131,7 +131,7 @@ Configuration Impact
 The middleware will be configurable:
 
 * path: url path of this middleware (default: /healthcheck)
-* backends: list of stevedore extention to use
+* backends: list of stevedore extension to use
 
 And the DisablebyfileHealthcheck with:
 

specs/liberty/dynamic-policies-overlay.rst

@@ -112,7 +112,7 @@ Incubation
 Adoption
 --------
 
-Any service using the ``Dynamic Policies`` mechanism for access controll will
+Any service using the ``Dynamic Policies`` mechanism for access control will
 be using the proposed change through ``Keystone Middleware``, which means that
 adoption is transparent to services.
 

specs/liberty/graduate-oslo-reports.rst

@@ -4,7 +4,7 @@
 
 https://blueprints.launchpad.net/oslo-incubator/+spec/graduate-oslo-reports
 
-The `reports` module currently provides a convienient way to assemble
+The `reports` module currently provides a convenient way to assemble
 "Guru Meditation Reports" about the current state a of a given OpenStack
 process.  The basic report includes thread (both normal and green) state
 and stack traces, as well as configuration and version information.  The

specs/mitaka/rabbitmq-pika-driver.rst

@@ -36,16 +36,16 @@ In this specification I propose to create fully new driver which:
 Features and it's design
 ------------------------
 
-During oslo.messaging driver investigation I seperated a few main
+During oslo.messaging driver investigation I separated a few main
 supported features:
 
 #. RPC - unreliable fast sending of the message to single remote server
    defined using target and getting reply.
    It has small timeout (a couple of seconds) therefore this
-   message should be recieved by server and processed in real time
+   message should be received by server and processed in real time
    (defined by timeout) or be skipped otherwise.
 #. CAST - unrelieble sending of the message to set of remote servers
-   defined by target. This message should be recieved by server in real time
+   defined by target. This message should be received by server in real time
    (defined by timeout) or be skipped otherwise. If somehow service
    does not listen the topic or some connectivity problem occurs
    and we can not recover it fast - this server will never get the message.

specs/newton/policy-in-yaml.rst

@@ -88,7 +88,7 @@ I don't know if the YAML parser is a lot slower, but since it supports several
 representations for the same result I assume it takes more work to parse it.
 The policy file is read when the server starts and also whenever the file
 changes (it used to be read on every request, but that's been changed to check
-the modification time), so I don't think this is going to be noticable.
+the modification time), so I don't think this is going to be noticeable.
 
 Configuration Impact
 --------------------

specs/policy/policy-merge.rst

@@ -120,7 +120,7 @@ this:
 Developer Impact
 ----------------
 
-API Developers wokring on policy will be able to think in terms of
+API Developers working on policy will be able to think in terms of
 common policy fragments.