openstack/nova
Code Issues Proposed changes

Fix seven typos on nova documentation

Browse Source 
behaviour => behavior 4
poicy => policy
schedular => scheduler
environement => environment

Change-Id: Id899cf127e30175486c3728e47e03dca3a32873a
Closes-Bug: #1478003
This commit is contained in:
Atsushi SAKAI 2015-07-24 22:57:13 +09:00
parent 0d696adcea
commit 24f292e0ca
4 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/source/api_microversion_dev.rst
View File

@ -60,7 +60,7 @@ This method would only be available if the caller had specified an
``X-OpenStack-Nova-API-Version`` of <= ``2.4``. If ``2.5`` or later
is specified the server will respond with ``HTTP/404``.
Changing a method's behaviour
Changing a method's behavior
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In the controller class::
@ -123,12 +123,12 @@ When not using decorators
~~~~~~~~~~~~~~~~~~~~~~~~~
When you don't want to use the ``@api_version`` decorator on a method
or you want to change behaviour within a method (say it leads to
or you want to change behavior within a method (say it leads to
simpler or simply a lot less code) you can directly test for the
requested version with a method as long as you have access to the api
request object (commonly called ``req``). Every API method has an
api_version_request object attached to the req object and that can be
used to modify behaviour based on its value::
used to modify behavior based on its value::
def index(self, req):
<common code>

2
doc/source/policy_enforcement.rst
View File

@ -115,7 +115,7 @@ group them, and put them in different policy configure file in policy.d
* Nova V2 API: After we move to V2.1, we needn't spend time to change V2
api rule, and needn't to bother deployer upgrade their policy config. So
just keep V2 API poicy rule named as before.
just keep V2 API policy rule named as before.
* Nova V2.1 API: We name the policy rule as
"os_compute_api:[extension]:[action]". The core API may be changed in

4
doc/source/testing/libvirt-numa.rst
View File

@ -298,7 +298,7 @@ The guest can now be started again, and ssh back into it
Before starting OpenStack services again, it is necessary to
reconfigure Nova to enable the NUMA schedular filter. The libvirt
reconfigure Nova to enable the NUMA scheduler filter. The libvirt
virtualization type must also be explicitly set to KVM, so that
guests can take advantage of nested KVM.
@ -476,7 +476,7 @@ Testing instance boot with 1 NUMA cell requested
Moving forward a little, explicitly tell Nova that the NUMA topology
for the guest should have a single NUMA node. This should operate
in an identical manner to the default behaviour where no NUMA policy
in an identical manner to the default behavior where no NUMA policy
is set. To define the topology we will create a new flavor
.. code-block:: bash

2
doc/source/testing/serial-console.rst
View File

@ -5,7 +5,7 @@ Testing Serial Console
The main aim of this feature is exposing an interactive web-based
serial consoles through a web-socket proxy.
This page describes how to test it from a devstack environement.
This page describes how to test it from a devstack environment.
---------------------------------
Setting up a devstack environment