Merge "Fix grammar issues"

This commit is contained in:
Zuul 2020-11-17 18:21:41 +00:00 committed by Gerrit Code Review
commit 5917863ced
5 changed files with 19 additions and 18 deletions

View File

@ -1,10 +1,10 @@
If you would like to contribute to the development of oslo's libraries,
first you must take a look to this page:
first you must take a look at this page:
https://specs.openstack.org/openstack/oslo-specs/specs/policy/contributing.html
If you would like to contribute to the development of OpenStack,
you must follow the steps in this page:
you must follow the steps on this page:
https://docs.openstack.org/infra/manual/developers.html

View File

@ -3,7 +3,7 @@
=======================
oslo.policy uses oslo.config to define and manage configuration options
to allow the deployer to control where the policy files are located and
the default rule to apply when policy etc.
that allow the deployer to control where the policy files are located,
the default rule to apply, etc.
.. show-options:: oslo.policy

View File

@ -35,7 +35,7 @@ entry point and will try to invoke that stevedore plugin.
This mechanism allows anyone to write their own code, in their own library
with their own custom stevedore based rule check plugins and can enhance
their policies with custom checks. This would be useful for example to
integrate with a in-house policy server.
integrate with an in-house policy server.
Example code - HttpCheck

View File

@ -23,7 +23,7 @@ where:
``policy_generator_config_file``
Path to an configuration file used with the ``oslopolicy-sample-generator``
utility. This can be an full path or a value relative to the documentation
utility. This can be a full path or a value relative to the documentation
source directory (``app.srcdir``). If this option is not specified or is
invalid then the sample policy file generation will be skipped.
@ -34,8 +34,8 @@ where:
``sample_policy_basename``
Base name of the output file. This name will be appended with a
``.policy.yaml.sample`` extension to generate the final output file and the
path is relative to documentation source directory (``app.srcdir``). As such,
``.policy.yaml.sample`` extension to generate the final output file, and the
path is relative to the documentation source directory (``app.srcdir``). As such,
using the above example, the policy file will be output to
``_static/nova.policy.yaml.sample``. If this option is not specified, the
file will be output to ``sample.policy.yaml``.

View File

@ -19,8 +19,8 @@ Incorporating oslo.policy tooling
The ``oslo.policy`` library offers a generator that projects can use to render
sample policy files, check for redundant rules or policies, among other things.
This is a useful tool not only for operators managing policies, but also
developers looking to automate documentation describing the projects default
This is a useful tool not only for operators managing policies but also for
developers looking to automate documentation describing projects' default
policies.
This part of the document describes how you can incorporate these features into
@ -39,7 +39,7 @@ First, you'll need to expose a couple of entry points in the project's
foo = foo.common.policy:get_enforcer
The ``oslo.policy`` library uses the project namespace to call ``list_rules``,
which should return a list of ``oslo.policy`` objects, either instances of
which should return a list of ``oslo.policy`` objects, instances of either
``RuleDefault`` or ``DocumentedRuleDefault``.
The second entry point allows ``oslo.policy`` to generate complete policy from
@ -129,7 +129,7 @@ benefits.
providing better documentation.
* A sample policy file can be generated based on the registered policies
rather than needing to manually maintain one.
rather than needing to be manually maintained.
* A policy file can be generated which is a merge of registered defaults and
policies loaded from a file. This shows the effective policy in use.
@ -174,7 +174,7 @@ class::
The `DocumentedRuleDefault` class inherits from the `RuleDefault`
implementation, but it must be supplied with the `description` attribute in
order to be used. In addition, the `DocumentedRuleDefault` class requires a new
`operations` attributes that is a list of dictionaries. Each dictionary must
`operations` attribute that is a list of dictionaries. Each dictionary must
have a `path` and a `method` key. The `path` should map to the path used to
interact with the resource the policy protects. The `method` should be the HTTP
verb corresponding to the `path`. The list of `operations` can be supplied with
@ -269,9 +269,9 @@ Putting it all together
~~~~~~~~~~~~~~~~~~~~~~~
Now that you know what services types, resources, attributes, and actions are
within the context of policy names, let establish the order you should use
them. Policy names should increase in detail as you read it. This results in
the following syntax::
within the context of policy names, it is possible to establish the order you
should use them. Policy names should increase in detail as you read it. This
results in the following syntax::
<service-type>:<resource>[:<subresource>][:<attribute>]:<action>[:<subaction>]
@ -341,7 +341,8 @@ for a user with a project-scoped token to access a system-level API.
Developers incorporating `scope_types` into OpenStack services should be
mindful of the relationship between the API they are protecting with a policy
and if it operates on system-level resources or project-level resources.
and the resource level the API operates at, whether it's system-level or
project-level.
Sample file generation
----------------------
@ -475,7 +476,7 @@ which determines if a user is allowed to do something.
The coupling between the authorization context, ultimately the token, and the
policy enforcement mechanism raises the bar for effectively testing policies
and APIs. Service developers want to ensure the functionality specific to their
service works, and not dwell on the implementation details of an authorization
service works and not dwell on the implementation details of an authorization
system. Additionally, they want to keep unit tests lightweight, as opposed to
requiring a separate system to issue tokens for authorization, crossing the
boundary of unit testing to integration testing.