Correct style errors

These style errors weren't caught before the specs merged because the
linter jobs weren't being run when only RST files were changed. Correct
them now so that a later patch can update the jobs.

Change-Id: I1c24cece2c64c9453698280cc365ac150d2474a4

specs/keystone/train/capabilities-app-creds.rst

@@ -84,8 +84,8 @@ by keystonemiddleware as follows:
 
    (a) A URL path (e.g. `/v2.1/servers`, `/v2.1/servers/*` or
        `/v2.1/servers/{server_id}`). This URL path must be explicitly permitted
-       according to an operator-configured list of access rules (see `Access Rules
-       Config`_ below).
+       according to an operator-configured list of access rules (see `Access
+       Rules Config`_ below).
    (b) A request method (e.g. `GET`)
    (c) A service type (ideally matching the `published Service Types Authority`_)
        from the Keystone service catalog.
@@ -108,9 +108,9 @@ by keystonemiddleware as follows:
    (c) The request method (e.g. `GET`)
 
    Against every entry in the access rule list retrieved from the token. If an
-   access rule matches the request, checking stops and the request is handed over
-   to `oslo.policy` for the regular role based checking. If no access rules
-   match, the request is rejected right away.
+   access rule matches the request, checking stops and the request is handed
+   over to `oslo.policy` for the regular role based checking. If no access
+   rules match, the request is rejected right away.
 
    There are three special cases to access rule list processing:
 
@@ -120,8 +120,8 @@ by keystonemiddleware as follows:
    (b) If an empty list is provided (i.e. `[]`), all requests are rejected
        (even if the request would otherwise pass the test in (c).
    (c) If there is a valid service token in the request, `keystonemiddleware`
-       passes the request to `oslo.policy` right away, though a future iteration
-       of this feature will enable a toggle to control this behavior.
+       passes the request to `oslo.policy` right away, though a future
+       iteration of this feature will enable a toggle to control this behavior.
 
 .. _published Service Types Authority: https://service-types.openstack.org/
 
@@ -182,8 +182,8 @@ An example creation request for an application credential looks as follows::
         }
     }
 
-With this, two new access rules will be created under the user's ID. They can be
-queried like this:
+With this, two new access rules will be created under the user's ID. They can
+be queried like this:
 
 Request::
 
@@ -312,19 +312,19 @@ Access Rules Config
 A future iteration of this feature may enable a way for operators to restrict
 the allowed access rules that a user may configure by creating a global
 whitelist of access rules against which users' access rules are validated prior
-to the creation of the application credential. The value of this would be to assist
-users in creating valid access rules by validating them against known working
-rules. It would also give the operator more control of the overall access
-control configuration. However, for the time being, this feature is infeasible
-because we lack discoverability of APIs and it is impossible to create a
-complete list of valid access rules for all services across OpenStack and
-external to OpenStack. Since providing a complete list is infeasible, leaving it
-up to the operator to curate their own list causes a poor operating experience
-for the operator and the list would be susceptible to mistakes, which in turn
-would cause an extremely poor user experience for the end user.
+to the creation of the application credential. The value of this would be to
+assist users in creating valid access rules by validating them against known
+working rules. It would also give the operator more control of the overall
+access control configuration. However, for the time being, this feature is
+infeasible because we lack discoverability of APIs and it is impossible to
+create a complete list of valid access rules for all services across OpenStack
+and external to OpenStack. Since providing a complete list is infeasible,
+leaving it up to the operator to curate their own list causes a poor operating
+experience for the operator and the list would be susceptible to mistakes,
+which in turn would cause an extremely poor user experience for the end user.
 
-When this feature becomes feasible, another possibility is to allow operators to
-configure a role ID for each access rule to indicate that the user needs to
+When this feature becomes feasible, another possibility is to allow operators
+to configure a role ID for each access rule to indicate that the user needs to
 provide that role in the application credential in order for the call to
 proceed. This allows for greater alignment between policy rules and access
 rules.

specs/keystone/train/immutable-resources.rst

@@ -22,13 +22,14 @@ Keystone is responsible for many resources that are used through out other
 services in an OpenStack deployment. For example, roles essentially map
 permissions to a string that can be associated to a user via a role assignment.
 Many roles are reused across OpenStack and some carry elevated authorization
-needed to manage the deployment. In some cases, the accidental removal of a role
-can be catastrophic to the deployment, since the deletion of a role triggers the
-deletion of all role assignments any user has in any scope for that role. This
-is particularly relevant to service users, which usually have an admin role
-assignment, without which they cannot perform basic operations needed for the
-cloud to be usable. The fix in such a case usually requires modifying database
-entries by hand, which is a terrible practice in production environments.
+needed to manage the deployment. In some cases, the accidental removal of a
+role can be catastrophic to the deployment, since the deletion of a role
+triggers the deletion of all role assignments any user has in any scope for
+that role. This is particularly relevant to service users, which usually have
+an admin role assignment, without which they cannot perform basic operations
+needed for the cloud to be usable. The fix in such a case usually requires
+modifying database entries by hand, which is a terrible practice in production
+environments.
 
 Keystone should implement a more robust mechanism that allows operators to lock
 specific resources, like important roles. A locked resource shouldn't be
@@ -51,11 +52,11 @@ implement this in steps:
 #. Add an ``immutable`` resource option to the role model. This will be off by
    default, always.
 
-#. Add an opt-in flag ``--immutable-roles`` to the ``keystone-manage bootstrap``
-   command which sets the ``immutable`` resource option on the default roles
-   (``admin``, ``member``, ``reader``) to ``true``. The command should also log
-   a warning that this will become default behavior in the future if they do not
-   set it.
+#. Add an opt-in flag ``--immutable-roles`` to the ``keystone-manage
+   bootstrap`` command which sets the ``immutable`` resource option on the
+   default roles (``admin``, ``member``, ``reader``) to ``true``. The command
+   should also log a warning that this will become default behavior in the
+   future if they do not set it.
 
 #. Add a ``keystone-status`` check to alert operators if they have not made the
    default roles immutable.
@@ -75,8 +76,8 @@ Alternatives
   assignments are hard-deleted, but could make it easier to recover since the
   role ID still resides in the database.
 
-* Change horizon to give a visual alert for potentially destructive actions like
-  deleting the admin role. This doesn't protect against bad scripts.
+* Change horizon to give a visual alert for potentially destructive actions
+  like deleting the admin role. This doesn't protect against bad scripts.
 
 Security Impact
 ---------------
@@ -93,8 +94,8 @@ Other End User Impact
 
 Administrative users will need to unset the ``immutable`` flag for a role if
 they truly want to delete or alter the role. Client changes will be needed to
-allow the adminitrator to set a role as immutable or mutable. Non-administrative
-end users should see no difference.
+allow the adminitrator to set a role as immutable or mutable.
+Non-administrative end users should see no difference.
 
 Performance Impact
 ------------------

specs/keystone/train/resource-options-for-all.rst

@@ -135,4 +135,4 @@ Documentation on adding new resource options will be needed.
 References
 ==========
 
-N/A
+N/A