Minor typo corrections

This change includes:
* a follow-up to [1] to fix the typos pointed out during review
* title fixes for two specs having the same title in the TOC
* two other typos

[1] https://review.openstack.org/545826
    I3860a62420ab4983e2b741dff04498fbb0432d00

Change-Id: I4ebb090de53370708e871c75c789b62bc5e71010
This commit is contained in:
Thomas Morin 2018-05-17 10:02:50 +02:00
parent cf38b6af27
commit 77f36d5f89
3 changed files with 16 additions and 16 deletions

View File

@ -72,7 +72,7 @@ resource on a Neutron instance will refer to both a local resource (e.g.
Router A) and a remote resource (OpenStack B:Router B), and will have the Router A) and a remote resource (OpenStack B:Router B), and will have the
semantic that connectivity is desired between the two. semantic that connectivity is desired between the two.
This resource will be part of two sort of API calls: This resource will be part of two sorts of API calls:
A. calls between the user having the connectivity need and each Neutron A. calls between the user having the connectivity need and each Neutron
instance involved; the role of these calls is to let the need for instance involved; the role of these calls is to let the need for
@ -131,7 +131,7 @@ B. API calls between a Neutron instance and another Neutron instance; the role
Note that the order between A1/A2/B1/B2 can vary, but the result is Note that the order between A1/A2/B1/B2 can vary, but the result is
unchanged: at least one of the two Neutron instances will eventually confirm unchanged: at least one of the two Neutron instances will eventually confirm
that the interconnection has been defined on both side symmetrically, and the that the interconnection has been defined on both side symmetrically, and the
interconnection setup phase will ultimate proceed on both sides (see interconnection setup phase will ultimately proceed on both sides (see
:ref:`details`). :ref:`details`).
When more than two OpenStack deployments, or more than two OpenStack regions, When more than two OpenStack deployments, or more than two OpenStack regions,
@ -159,20 +159,20 @@ and to keep interconnections isolated from one another, are not controlled
by consumers of this API. In this proposal these consumers do not and cannot by consumers of this API. In this proposal these consumers do not and cannot
write, or even read, these identifiers. write, or even read, these identifiers.
Note that only the API calls to the 'interconnection' resources at step A Note that only the API calls to the 'interconnection' resources at steps A1/A2
require write access to the "interconnection" resources by tenant users (but require write access to the "interconnection" resources by tenant users (but
not to the attributes related to the network mechanism to use). not to the attributes related to the network mechanism to use).
The calls at steps B, only require read-only access to these resources; The calls at steps B1/B2, only require read-only access to these resources;
this can be achieved by introducing an "interconnection" role with read-only this can be achieved by introducing an "interconnection" role with read-only
access to all "interconnection" resources, and having each OpenStack deployment access to all "interconnection" resources, and having each OpenStack deployment
having credentials for a user with this role in other OpenStack deployments. having credentials for a user with this role in other OpenStack deployments.
With the above in mind, Keystone federation is not required for the calls at With the above in mind, Keystone federation is not required for the calls at
step 1, nor for the calls at step 2. However, using Keystone Federation for steps A1/A2, nor for the calls at step B1/B2. However, using Keystone
the user(s) used at step 2 will certainly be useful and avoid requiring the Federation for the user(s) used at step B1/B2 will certainly be useful and
management in each Neutron instance of the credentials to use to each other will avoid requiring the management in each Neutron instance of the
OpenStack. credentials to use to each other OpenStack.
Interconnection mechanisms Interconnection mechanisms
-------------------------- --------------------------

View File

@ -4,9 +4,9 @@
http://creativecommons.org/licenses/by/3.0/legalcode http://creativecommons.org/licenses/by/3.0/legalcode
================================================== ==================================================================
Decoupling database imports/access for neutron-lib Decoupling database API & Utilities imports/access for neutron-lib
================================================== ==================================================================
This work is not related to an enhancement request and therefore doesn't have This work is not related to an enhancement request and therefore doesn't have
a RFE. Rather the intent herein is to discuss how we decouple ``neutron.db`` a RFE. Rather the intent herein is to discuss how we decouple ``neutron.db``
@ -23,7 +23,7 @@ categories:
As the database access patterns span a wide range of logic/code, a set of specs As the database access patterns span a wide range of logic/code, a set of specs
will be proposed each focusing on a single access pattern. will be proposed each focusing on a single access pattern.
This spec specifically address the Database API & Utilities access. This spec specifically addresses the Database API & Utilities access.
For current neutron-lib related blueprints, see [1]_ and [2]_. For current neutron-lib related blueprints, see [1]_ and [2]_.

View File

@ -4,9 +4,9 @@
http://creativecommons.org/licenses/by/3.0/legalcode http://creativecommons.org/licenses/by/3.0/legalcode
================================================== =================================================================
Decoupling database imports/access for neutron-lib Decoupling database Resource Model imports/access for neutron-lib
================================================== =================================================================
This work is not related to an enhancement request and therefore doesn't have This work is not related to an enhancement request and therefore doesn't have
a RFE. Rather the intent herein is to discuss how we decouple ``neutron.db`` a RFE. Rather the intent herein is to discuss how we decouple ``neutron.db``
@ -23,7 +23,7 @@ categories:
As the database access patterns span a wide range of logic/code, a set of specs As the database access patterns span a wide range of logic/code, a set of specs
will be proposed each focusing on a single access pattern. will be proposed each focusing on a single access pattern.
This spec specifically address Database Resource Model access. This spec specifically addresses Database Resource Model access.
For current neutron-lib related blueprints, see [1]_ and [2]_. For current neutron-lib related blueprints, see [1]_ and [2]_.