From 12c1f728dc2ffcb27a4903efc82241c78fa04964 Mon Sep 17 00:00:00 2001 From: howardlee Date: Tue, 1 Nov 2016 16:19:59 +0800 Subject: [PATCH] Fix typos in oslo-specs TrivialFix Change-Id: Id4166c4e5941061a65cf7aafaa748a60286caadd --- specs/juno/rootwrap-daemon-mode.rst | 4 ++-- specs/kilo/oslo-middleware-healthcheck.rst | 8 ++++---- specs/liberty/dynamic-policies-overlay.rst | 2 +- specs/liberty/graduate-oslo-reports.rst | 2 +- specs/mitaka/rabbitmq-pika-driver.rst | 6 +++--- specs/newton/policy-in-yaml.rst | 2 +- specs/policy/policy-merge.rst | 2 +- 7 files changed, 13 insertions(+), 13 deletions(-) diff --git a/specs/juno/rootwrap-daemon-mode.rst b/specs/juno/rootwrap-daemon-mode.rst index 6fd005a..268c38a 100644 --- a/specs/juno/rootwrap-daemon-mode.rst +++ b/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 diff --git a/specs/kilo/oslo-middleware-healthcheck.rst b/specs/kilo/oslo-middleware-healthcheck.rst index 6cb3d1a..aac1a75 100644 --- a/specs/kilo/oslo-middleware-healthcheck.rst +++ b/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 " 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: diff --git a/specs/liberty/dynamic-policies-overlay.rst b/specs/liberty/dynamic-policies-overlay.rst index bb174e7..54f6ed0 100644 --- a/specs/liberty/dynamic-policies-overlay.rst +++ b/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. diff --git a/specs/liberty/graduate-oslo-reports.rst b/specs/liberty/graduate-oslo-reports.rst index 47f8ab1..3a56350 100644 --- a/specs/liberty/graduate-oslo-reports.rst +++ b/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 diff --git a/specs/mitaka/rabbitmq-pika-driver.rst b/specs/mitaka/rabbitmq-pika-driver.rst index 23f9c72..a86b81a 100644 --- a/specs/mitaka/rabbitmq-pika-driver.rst +++ b/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. diff --git a/specs/newton/policy-in-yaml.rst b/specs/newton/policy-in-yaml.rst index 07eaaad..64443a1 100644 --- a/specs/newton/policy-in-yaml.rst +++ b/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 -------------------- diff --git a/specs/policy/policy-merge.rst b/specs/policy/policy-merge.rst index 17a3563..189d5cf 100644 --- a/specs/policy/policy-merge.rst +++ b/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.