Browse Source

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
Thomas Morin 11 months ago
parent
commit
77f36d5f89

+ 8
- 8
specs/rocky/neutron-inter.rst View File

@@ -72,7 +72,7 @@ resource on a Neutron instance will refer to both a local resource (e.g.
72 72
 Router A) and a remote resource (OpenStack B:Router B), and will have the
73 73
 semantic that connectivity is desired between the two.
74 74
 
75
-This resource will be part of two sort of API calls:
75
+This resource will be part of two sorts of API calls:
76 76
 
77 77
 A. calls between the user having the connectivity need and each Neutron
78 78
    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
131 131
 Note that the order between A1/A2/B1/B2 can vary, but the result is
132 132
 unchanged: at least one of the two Neutron instances will eventually confirm
133 133
 that the interconnection has been defined on both side symmetrically, and the
134
-interconnection setup phase will ultimate proceed on both sides (see
134
+interconnection setup phase will ultimately proceed on both sides (see
135 135
 :ref:`details`).
136 136
 
137 137
 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
159 159
 by consumers of this API. In this proposal these consumers do not and cannot
160 160
 write, or even read, these identifiers.
161 161
 
162
-Note that only the API calls to the 'interconnection' resources at step A
162
+Note that only the API calls to the 'interconnection' resources at steps A1/A2
163 163
 require write access to the "interconnection" resources by tenant users (but
164 164
 not to the attributes related to the network mechanism to use).
165 165
 
166
-The calls at steps B, only require read-only access to these resources;
166
+The calls at steps B1/B2, only require read-only access to these resources;
167 167
 this can be achieved by introducing an "interconnection" role with read-only
168 168
 access to all "interconnection" resources, and having each OpenStack deployment
169 169
 having credentials for a user with this role in other OpenStack deployments.
170 170
 
171 171
 With the above in mind, Keystone federation is not required for the calls at
172
-step 1, nor for the calls at step 2. However, using Keystone Federation for
173
-the user(s) used at step 2 will certainly be useful and avoid requiring the
174
-management in each Neutron instance of the credentials to use to each other
175
-OpenStack.
172
+steps A1/A2, nor for the calls at step B1/B2. However, using Keystone
173
+Federation for the user(s) used at step B1/B2 will certainly be useful and
174
+will avoid requiring the management in each Neutron instance of the
175
+credentials to use to each other OpenStack.
176 176
 
177 177
 Interconnection mechanisms
178 178
 --------------------------

+ 4
- 4
specs/rocky/neutronlib-decouple-db-apiutils.rst View File

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

+ 4
- 4
specs/rocky/neutronlib-decouple-models.rst View File

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

Loading…
Cancel
Save