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
|
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
|
||||||
--------------------------
|
--------------------------
|
||||||
|
|
|
@ -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]_.
|
||||||
|
|
||||||
|
|
|
@ -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]_.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue