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:
parent
cf38b6af27
commit
77f36d5f89
|
@ -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
|
||||
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
|
||||
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
|
||||
unchanged: at least one of the two Neutron instances will eventually confirm
|
||||
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`).
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
access to all "interconnection" resources, and having each OpenStack deployment
|
||||
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
|
||||
step 1, nor for the calls at step 2. However, using Keystone Federation for
|
||||
the user(s) used at step 2 will certainly be useful and avoid requiring the
|
||||
management in each Neutron instance of the credentials to use to each other
|
||||
OpenStack.
|
||||
steps A1/A2, nor for the calls at step B1/B2. However, using Keystone
|
||||
Federation for the user(s) used at step B1/B2 will certainly be useful and
|
||||
will avoid requiring the management in each Neutron instance of the
|
||||
credentials to use to each other OpenStack.
|
||||
|
||||
Interconnection mechanisms
|
||||
--------------------------
|
||||
|
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
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
|
||||
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
|
||||
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]_.
|
||||
|
||||
|
|
|
@ -4,9 +4,9 @@
|
|||
|
||||
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
|
||||
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
|
||||
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]_.
|
||||
|
||||
|
|
Loading…
Reference in New Issue