openstack
/
neutron
Code Issues Proposed changes

Trivial fix typos while reading doc 

Change-Id: I704a176664fd7a980309d7ff7a5021b1e4c4b033
This commit is contained in:
Ngo Quoc Cuong 2017-05-06 00:02:18 +07:00
parent 3c014b854a
commit a7df10146a
6 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/devref/images/live-mig-ovs-hybrid.txt
View File

@ -82,7 +82,7 @@ note over nova_compute1, nova_compute2
end note
note left of nova_compute1
live migration
succeded
succeeded
end note
nova_compute1 -> nova_compute1 : post_live_migration

2
doc/source/devref/images/live-mig.txt
View File

@ -107,7 +107,7 @@ end
note left of nova_compute1
live migration
succeded
succeeded
end note
nova_compute1 -> nova_compute1 : post_live_migration

2
doc/source/devref/policy.rst
View File

@ -256,7 +256,7 @@ served by Neutron "core" and for the APIs served by the various Neutron
* There is still only one check which is hardcoded in Neutron's API layer:
the check to verify that a project owns the network on which it is creating
a port. This check is hardcoded and is always executed when creating a
port, unless the network is shared. Unfortunatelu a solution for performing
port, unless the network is shared. Unfortunately a solution for performing
this check in an efficient way through the policy engine has not yet been
found. Due to its nature, there is no way to override this check using the
policy engine.

4
doc/source/policies/bugs.rst
View File

@ -228,7 +228,7 @@ The process of bug triaging consists of the following steps:
* Check if a bug was filed for a correct component (project). If not, either
change the project or mark it as "Invalid".
* For bugs that affect documenation (including autogenerated DocImpact bugs)
* For bugs that affect documentation (including autogenerated DocImpact bugs)
proceed like this. If documentation affects
* the ReST API, add "openstack-api-site" to the affected projects.
@ -297,7 +297,7 @@ Check for Bugs with the 'timeout-abandon' tag:
* Search for any bugs with the timeout abandon tag:
`Timeout abandon <https://bugs.launchpad.net/neutron/+bugs?field.tag=timeout-abandon>`_.
This tag indicates that the bug had a patch associated with it that was
automatically abandonded after a timing out with negative feedback.
automatically abandoned after a timing out with negative feedback.
* For each bug with this tag, determine if the bug is still valid and update
the status accordingly. For example, if another patch fixed the bug, ensure
it's marked as 'Fix Released'. Or, if that was the only patch for the bug and

2
doc/source/policies/release-checklist.rst
View File

@ -47,7 +47,7 @@ New major release process contains several phases:
#. at this point, master branch is open for patches targeted to the next
release; PTL unblocks all patches that were blocked in step 1;
#. if additional patches are identified that are critical for the release and
must be shipped in the final major build, correpsponding bugs are tagged
must be shipped in the final major build, corresponding bugs are tagged
with <release>-rc-potential in Launchpad, fixes are prepared and land in
master branch, and are then backported to the newly created stable branch;
#. if patches landed in the release stable branch as per the previous step, a

2
doc/source/stadium/governance.rst
View File

@ -245,7 +245,7 @@ Checklist
The `neutron-lib patch <https://review.openstack.org/#/c/353131/>`_
introduces the elements that define the API, and testing coverage
validates that the resource and actions maps use valid keywords.
API reference documention is provided alongside the definition to
API reference documentation is provided alongside the definition to
keep everything in one place.
The `neutron patch <https://review.openstack.org/#/c/353132/>`_
uses the Neutron extension framework to plug the API definition