| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
TrivialFix
Change-Id: I0a9f18e31492b5b5bd5de004e8f5129d8fd3f50f
|
| |\ |
|
| | |
| |
| |
| |
| | |
Change-Id: I9a9161f797d89543ae189bd35f61e00524b481a1
TrivialFix
|
| |/
|
|
|
|
|
|
|
| |
The docs for the policy sample generator were inconsistent with how it
is typically used in practice, with just one namespace. This led to
questions about using one namespace when in reality that's what happens.
This patch brings the example more in line with reality.
Change-Id: Id3c21459eff09aaf6e31c6f3aa4f8d829f87c513
|
| |
|
|
|
|
|
|
| |
Provide a way to include a sample policy file in a project's
documentation. This harnesses the same generator utilities used in
standard policy file generation.
Change-Id: I4b04044c18ea9f2b1d55785686982af9032a8495
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two helper scripts that consuming projects can use to get
information that helps deployers.
The oslopolicy-policy-generator script looks at an entry_point for a
configured policy.Enforcer and outputs a yaml formatted policy file for
that configuration. This is a merge of registered rules and configured
rules.
The oslopolicy_list_redundant script looks at an entry_point for a
configured policy.Enforcer and outputs a yaml formatted policy file with
a list of policies where the registered default matches the project
configuration. These are policies that can be removed from the
configuration file(s) without affecting policy.
Change-Id: Ibe4e6c9288768bcc8f532e384524580c57e58275
Implements: bp policy-sample-generation
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a console script to oslo.policy that will output a sample
policy file in yaml format. It works by looking at the configured
namespace(s) under an 'oslo.policy.policies' entry point. A method, or
methods, should be provided which return a list of
oslo_policy.policy.RuleDefault objects.
To use this script add an entry to setup.cfg in a project with something
like:
oslo.policy.policies =
nova.api = nova.api.opts:list_policies
list_policies should be a method which returns a list of
oslo_policy.policy.RuleDefault objects.
Then run it like:
oslopolicy-sample-generator --namespace nova.api
--output-file can also be specified, or those options can be configured
in a file which can be specified with --config-file.
Change-Id: If25d48313b91a6610119220e13f635c6e28b2a59
Partially-Implements: bp policy-sample-generation
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A new RuleDefault class has been added which can be used to register
policies that will be used by a consumer of oslo.policy. These policies
are merged with those defined in policy files, with the file definitions
overriding the defaults
Registering a policy with the same name twice is considered an error and
will raise a DuplicateRuleDefaultError exception.
To facilitate projects wishing to ensure that all policies are
registered before use an authorize method has been added which errors
when checking an unregistered policy. If the policy has been registered
then the enforce method is called in the normal manner.
Change-Id: I3b6423aeed8ae80e8bf73dbda0f63ef379ccef43
Implements: bp policy-in-code
|
| |/
|
|
|
|
| |
We should import cfg from oslo_config, not keystone.
Change-Id: I79e3dc573727400d1f6f6474c221726796a6ece2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows testing the access_data from a Keystone token against
all rules in a policy file.
Optionally can test a single rule. See
$ tox -e venv -- oslopolicy-checker --help
For more details
Co-Authored-By: Ian Cordasco <graffatcolmingov@gmail.com>
Implements-Blueprint: oslopolicy-cli
Change-Id: I8b2e8739c85077e856775f37e9868eb0a8babb3c
|
| |
|
|
|
|
|
|
| |
Acoording to pbr's usage [1], we should avoid generating
doc from test.
[1] https://github.com/openstack-dev/pbr/blob/master/doc/source/index.rst#pbr
Change-Id: Iea24bd9ac713ff6c093eac88e03ebf5dbd0eabc1
|
| |
|
|
|
|
|
| |
Add automatically generated documentation for the configuration options
using oslo_config.sphinxext.
Change-Id: I18faeb6c32dec69d3ecb4986317cada2af3632f8
|
| |
|
|
|
|
|
| |
- Automatically generate the API docs
- Makes the index on the modules index page useful
Change-Id: I4eafe2c64a0733f6fb81b20e85cd943355860f9a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Those classes are used in neutron to implement custom attribute
and sub-attribute checks (get_network:attr:subattr syntax).
Those checks do not belong to oslo.policy since they would be
backwards incompatible with existing behaviour, introducing new
semantics and potentially breaking other projects, like nova.
So the alternative is to expose those symbols as part of public
API for the oslo library and allow other projects to reuse them.
More details on neutron issues consuming the library can be
found at:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/061783.html
Related-Bug: #1426082
Change-Id: I6ee9f8f7fcea3ddb2c52b5d58dfce3dd328c9131
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move the option definitions into the opts module with the other
functions related to options.
Add set_defaults() to override the default settings for options and make
it part of the public API of the library by including it in the
documentation.
Add opts._register() so the options can be registered consistently from
multiple places.
Change-Id: Ib74beac58a07bf5ee0f92c2b7eda8281ef7d7c33
|
| |
|
|
|
|
|
|
|
|
| |
stylize the docs, and document the migration process, specifically
calling out the changes to the Enforcer class, which now required
an oslo.config config object to be passed in.
implements bp graduate-policy
Change-Id: Ief4395f3312b90adea1f05903b9498b730663a74
|
| |
|
|
|
|
|
|
|
| |
Clean up table formatting in the module header and add directive to
auto-doc the module.
Closes-Bug: #1415623
Change-Id: Iebf7e9cf88eae822d0d604a9557d45a170c679d9
|
| |
|
