As per the current release tested runtime, we test
python version from 3.8 to 3.11 so updating the
same in python classifier in setup.cfg
Change-Id: I850407259de142c1022ab06c04c6b8c035feaac4
In Zed cycle testing runtime, we are targetting to drop the
python 3.6/3.7 support, project started adding python 3.8 as minimum,
example nova:
- 56b5aed08c/setup.cfg (L13)
Change-Id: Icd143d8880666c1282e1e7821c108ab3e4de7813
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:
UserWarning: Usage of dash-separated 'description-file' will not be
supported in future versions. Please use the underscore name
'description_file' instead
[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb
Change-Id: I58b9521882d81ab508bb7ce28308d88771daf1fe
Add ``oslopolicy-convert-json-to-yaml`` tool which can be
used to convert the json formatted policy file to yaml format.
It takes json formatted policy file as input and convert it to
a yaml formatted policy file similar to 'oslopolicy-sample-generator'
tool except keeping the overridden rule as uncommented.
This tool does the following:
* Comment out any rules that match the default from policy-in-code.
* Keep rules uncommented if rule is overridden.
* Does not auto add the deprecated rules in the file unless it not already
present in the file.
* Keep any extra rules or already exist deprecated rules uncommented
but at the end of the file with a warning text.
I did not add the new functionality in existing 'oslopolicy-policy-upgrade'
tool because the above listed features of new tool end up creating a
complete different code path instead of reusing it from existing tool so it
better to have separate tool which can be removed in future once all deployments
are migrated to YAML formatted file.
This commits add doc and reno also for this tool
Partial implement blueprint policy-json-to-yaml
Change-Id: Icc245951b2992cc09a891516ffd14f3d4c009920
As requested in the referenced RFE bug, this is a validator tool
similar to the oslo.config validator tool that operators can use to
look for basic errors in their policy files.
It's very similar to the redundant rule tool, but I decided not to
combine them because I feel like the target use cases are enough
different to warrant separate tools. Specifically, the redundant
rule tool is looking for perfectly valid rules that just happen to
be unnecessary. The validator is looking for errors in the policy
file. While it's unlikely someone looking for redundant rules wouldn't
also want to know if there is something broken in their policy file,
it's likely that someone just looking to sanity check their policy
before deployment wouldn't want to see a bunch of messages about
redundant rules that won't cause any problems.
Change-Id: I799a754aceac080c11baffd7ff635b2a9cb825f7
Closes-Bug: 1853038
These translation sections are not needed anymore, Babel can
generate translation files without them.
Change-Id: I01d74cb5ff4701ca537dc3ec0f877b45cda7c895
Now that we are running the Victoria tests that include a
voting py38, we can now add the Python 3.8 metadata to the
package information to reflect that support.
Change-Id: I602d143c89792824a2f206cdb45667b2f97e2e67
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Add a new "oslopolicy-policy-upgrade" commnd. Using this command,
operator can upgrade their self-defined policy files to follow
the new format in the new release when upgrading OpenStack services.
Change-Id: Iad9740bd8a5e4fdf1d1e64d61bc93f2483c531f3
Why? HttpCheck/HttpsCheck are examples of rule checks
that can be implemented outside of the oslo.policy
library. Once we setup the infra for registering and
using these as stevedore extensions, we automatically
get the capability of other folks contributing to
writing custom rules for their own use cases.
* Add HttpCheck/HttpsCheck as entrypoints in setup.cfg
* parser will check get_extensions() to see if there
are any external checks registered
* Move HttpCheck/HttpsCheck into external module
* Move related test cases to test_external.py
Change-Id: Icde2b26a38d7c7842defae053228d9208454b969
With pbr 2.0 and Sphinx 1.5, the setting for treat sphinx warnings as
errors is setting warning-is-error in build_sphinx section. Migrate the
setting from the old warnerrors one.
There are some invalid docstrings. These are cleaned up.
Change-Id: Ic6a028bab428b23255f36e5b2d64ee8d4d32978d
Now that there exists only a gate job for Python 3.5 and not 3.4,
we should remove those references to the 3.4 that is untested.
Change-Id: I1459093004581ea89c95e38a90f199ab4930d4ea
Now that there is a passing gate job, we can claim support for
Python 3.5 in the classifier. This patch also adds the convenience
py35 venv.
Change-Id: I712c4e32e4db3e5ef826c69a11b8c3338753906f
The oslopolicy-policy-generator script was configured to use a method
named genarate_policy. Unfortunately that method does not exist but
there is one called generate_policy. This fixes the mistake.
Change-Id: I04125bb3305f695e156e901543393abfae527a09
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
Follow new infra setup for translations, see spec
http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
for full details.
This basically renames
oslo.policy/locale/oslo.policy.pot to
oslo_policy/locale/oslo_policy.pot. For this we need to update
setup.cfg.
Update also domain name in i18n.py.
The project has no translations currently, let's remove the outdated
pot file, the updated scripts work without them. So, we can just
delete the file and once there are translations, an updated pot file
together with translations can be imported automatically.
Change-Id: I9ca723834b1634a9ed965a92724d72fefc15e0d2
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
We have decided to remove Python 2.6 support, this commit
removes Python 2.6 classifier before dropping any Python
2.6 support in code.
Change-Id: I4de8aad0981f5af33964c1833410e79288938044
Provide a more complete description in README.rst, which is used
when viewing the library on pypi.
Also standardize the short-description used in setup.cfg.
Change-Id: Ia3b56ba2abfc0c2826bff8e10f31e196d5c4031b
Create entry points for oslo.policy, and make the necessary
changes to grouping the options into a new 'oslo_policy' group.
Change-Id: I32fd78c8a90fd2d49824db145362069b81fcaec5
Closes-Bug: #1415631
Ghanshyam Mann