| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Sphinx 1.8 introduced [1] the '--keep-going' argument which, as its name
suggests, keeps the build running when it encounters non-fatal errors.
This is exceptionally useful in avoiding a continuous edit-build loop
when undertaking large doc reworks where multiple errors may be
introduced.
[1] https://github.com/sphinx-doc/sphinx/commit/e3483e9b045
Change-Id: I9af0e8323b85d47983274b4d45b27f6c036ea5a8
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Without this patch, the policy checker issues a 'failed' result when
checking a system-scoped sample token against a policy string like
"role:admin and system_scope:all", because the policy checker does not
understand the 'system_scope' attribute that is now in oslo.context[1]
and wasn't parsing the "system" scope object from the sample token.
Similarly, it fails on a string like "user_id:%(user_id)s" because it
never looked up the user_id from the sample token. This change updates
the policy checker to understand token contexts and policies like these
so that more of the policy defaults in keystone, and soon other
projects, will pass. This also adds a new system-scoped sample token to
check against.
[1] https://review.opendev.org/530509
Change-Id: I02fbbc99d28aa5c787133f530f6e968341107bf7
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running the tool against a project with a lot of deprecated
policies, the deprecation warnings overwhelm the important output
from the tool. Since checking for deprecations isn't the purpose of
this tool, let's just suppress warnings and limit the output to the
list of redundant policy rules that the user cares about.
I will note that the suppress_deprecation_warnings member is marked
as test only, but that was targeted at consumers of oslo.policy
rather than oslo.policy itself. I could also argue that we're
"testing" for redundant policies here, but that feels like semantic
hair splitting. :-)
Change-Id: I194af14ebd341366dbb1dd033654739a7f3d085c
Partial-Bug: 1836568
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add file to the reno documentation build to show release notes for
stable/train.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/train.
Change-Id: I8cb1d87c0a6ab7da1918e69cd52fd40276717d5b
Sem-Ver: feature
|
| | |
| |
| |
| |
| |
| | |
For more detail, see http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006478.html
Change-Id: Ic8a10192e3971bbda6be45518ffe9c472369d353
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the sample policy generator, we create a rule that maps the
deprecated name of a policy to the new rule name. For example:
identity:old_rule: rule:identity:new_rule
However, in the policy code, if we see an override of a deprecated
name and no override for the new name, we apply the value of the
deprecated name to the new name. In the above case, this results
in us creating a rule that looks like:
identity:new_rule: rule:identity:new_rule
which is a circular reference and nonsense.
To fix this, I added a check to the deprecated rule logic that looks
for instances where the old override is just a reference to the new
rule. If that's the case, then we don't need to do anything because
it's already doing the right thing.
Change-Id: Ifd14993bc84e83c13abab3456fbf670c06e5806f
Closes-Bug: 1843931
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, oslo.policy would generate policy files with aliased names
in the event the name was changing for backwards compatibility. This
isn't needed if the name isn't changing and only the check string is
changing.
This patch adds a conditional to the generator logic that only aliases
the old name to the new name if the name is changing. Otherwise, it
only outputs comments about the deprecation.
Co-Authored-By: Ben Nemec <bnemec@redhat.com>
Change-Id: I89ff60354e4751a5096832023441d2e6166db92a
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Change-Id: I2f12fb5058984c1fc6beda4d13f934dd9b218218
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | | |
Change-Id: I7c761710e88d144fef4736295e8d9dd85bf72396
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Without this patch, if a project is going through a heavy policy
refactor, significant numbers of deprecation warnings are emitted. When
the enforcer is repeated reinitialized, as is the case when unit
testing, the vast amount of logs resulting from the warnings is both
unnecessary and harmful as it impedes log readability and explodes the
size of the logs, thereby causing CI instability as the infrastructure
struggles to process the logs.
This change adds a public attribute to the enforcer object to allow
callers to suppress these logs. This is not exposed as a configuration
option because we do not want to allow operators to suppress these logs,
and the warnings that occur when the enforcer is only reinitialized when
the process is reloaded are not nearly so debilitating as they are
during, e.g., a unit test run when the enforcer is generally
reinitialized for every test.
The Python warnings module allows for setting global attributes to
filter logs, and it might have been useful for the consuming project to
filter these logs at that level rather than modifying the policy
enforcer to turn log emissions on and off. The problem with this
approach is that if the number of deprecations is extreme, as may be the
case during a heavy refactor, the warnings filter can become so
inefficient that the test run can take much longer, causing even further
CI stability as test runs reach timeout limits.
Needed-by: https://review.opendev.org/673933
Change-Id: Ibfc7d4fca02b896953f80ddf1a9a8b9a19444f72
Related-bug: #1836568
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanically generated patch to ensure unit testing is in place
for all of the Tested Runtimes for Train.
See the Train python3-updates goal document for details:
https://governance.openstack.org/tc/goals/train/python3-updates.html
Change-Id: I64676b14b8a69d07e1b5fdc85e2a29523d4cf31d
Story: #2005924
Task: #34234
|
| |
|
|
| |
Change-Id: Iafa01298a49342ce8b0a1405d2d8ea2b61b3e198
|
| |\ |
|
| | |
| |
| |
| |
| | |
Change-Id: I06b5f84891c7d90837cfbbdbb532f8479620c6c7
Closes-Bug: #1827761
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bandit 1.6.0 accidentally changed how the exclusion list option is
handled and breaks our use of it. Cap to the previous version until
Bandit has fixed the problem.
Sphinx 2.0 no longer works on python 2.7, so we need to start capping
it there as well.
Change-Id: Idead9b4198c6b05d72bae60dee06e5aebc223822
Reference: https://github.com/PyCQA/bandit/pull/489
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
All the integration testing has been moved to
Bionic now[1] and py3.5 is not tested runtime for
Train or stable/stein[2].
As per below ML thread, we are good to drop the py35
testing now:
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/005097.html
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004647.html
[2]
https://governance.openstack.org/tc/reference/runtimes/stein.html
https://governance.openstack.org/tc/reference/runtimes/train.html
Change-Id: Ic757ff7963f1dabd70610a884a4c61e747cd3961
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit was bulk generated and pushed by the OpenDev sysadmins
as a part of the Git hosting and code review systems migration
detailed in these mailing list posts:
http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/004920.html
Attempts have been made to correct repository namespaces and
hostnames based on simple pattern matching, but it's possible some
were updated incorrectly or missed entirely. Please reach out to us
via the contact information listed at https://opendev.org/ with any
questions you may have.
|
| |
|
|
|
|
|
|
|
|
|
| |
This options help text was ambiguous and didn't really give readers
a good idea of what policies were or if the path could be relative,
absolute, or both.
This commit attempts to clarify the help text a little bit so that
readers have a little more to go on.
Change-Id: Icda67f07f0ef5ee256113634d29f4662b48140cc
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add file to the reno documentation build to show release notes for
stable/stein.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/stein.
Change-Id: I4ab63935e8382bd0e5903297f2a5cd424884b38b
Sem-Ver: feature
|
| |
|
|
|
|
|
| |
Previously the code snippet for tox.ini genpolicy pointed to the output yaml
instead of the config file.
Change-Id: Ia575beabad06f081d4f68bff8fcf83566331f1d6
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
With python3.6 and python3.7 jobs added to the Zuul jobs, it makes sense
to add this to the tox config too so that developers can run those
tests as well.
Change-Id: Iccc84a4336302b49a2d5e9a82518c06914f4794a
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously if a non-existent namespace was specified, we just got
a generic KeyError from stevedore that didn't say a whole lot about
what went wrong. You pretty much had to go read the code to figure
out what happened.
This change adds an explicit check for a missing namespace and raises
a KeyError with a more specific error message that explains what is
wrong.
Change-Id: Ia56d4655d70cee78661567188a977f67b7c3ee78
Closes-Bug: 1817953
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanically generated patch to add a unit test job running
under Python 3.7.
See ML discussion here [1] for context.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135626.html
Story: #2004073
Task: #27440
Change-Id: I52a1172779d901ce9f8525b87d7d15b0200b8674
|
| |
|
|
| |
Change-Id: I7009b639743c22f885cebd532a3d6c1b0f9f1226
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Reading configurations will enable us to be able to use the
oslopolicy-checker to do external checks (which require the
configuration in the enforcer).
Change-Id: If2e697f9ac0317046f5a872ad668b42c1b32eb1e
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
oslo.config already has a proper type to deal with boolean options.
Change-Id: I675c1dbfa13ca68506042f7907082b0e3d51672a
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | | |
Change-Id: If29fcf542c48a931edfebb7763d80f045c2fa0d7
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
By calling set_default[1] on a conf object it only applies to opts
registered to that object. This causes an incorrect value to appear in
the generated sample config because it deals with a list of raw opts,
not a conf object.
To fix this, we can call the global set_defaults[2] on the cfg module
which alters the opts directly. This is the method used in the cors
middleware[3] and works as expected there.
This does complicate the unit tests, however. Because we're altering
global state we need to save the original opts and restore them after
the test. Furthermore, the conf.reset() call in the config fixture
doesn't sufficiently reset the conf object to allow it to recognize
the replaced opts. For the purposes of this test we can just create
a standalone conf object though, which gets past that problem.
It's possible that we should fix reset() so it actually removes opts
in groups completely, but I'm unsure what implications that might
have for other users of the function.
1: https://github.com/openstack/oslo.config/blob/b5df53543fd3edbc369cacbdd1c3038bdce9085e/oslo_config/cfg.py#L2433
2: https://github.com/openstack/oslo.config/blob/b5df53543fd3edbc369cacbdd1c3038bdce9085e/oslo_config/cfg.py#L391
3: https://github.com/openstack/oslo.middleware/blob/8c7fa5bb105cdfd15376c6b1f42ef1383b7cb3eb/oslo_middleware/cors.py#L88
Change-Id: I3af9de1b39b6360ecfcb448d8c37b463e1a42ca7
Closes-Bug: 1807184
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
Changing arg consumption from argparse to oslo.config in
order to also provide behavior control using config files.
Change-Id: Iec4dab763b973b70c98077cb29708acd9cbbcec4
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
|
| |/
|
|
|
|
|
|
|
|
|
| |
Small cleanups:
* Use openstack-lower-constraints-jobs template, remove individual
jobs.
* Sort list of templates
Change-Id: If1babd86d4695fe216ff703ed862c3f06d448e15
Needed-By: https://review.openstack.org/623229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A previous commit made some changes to allow for more robust logging
of RBAC enforcement data:
I4642c57990b145c0e691140970574412682e66a5
This also included logging of the target data, which is provided by
the service calling policy enforcement.
This commit makes it so that target data is protected from exposing
sensitive information. A good example is doing operations on users
in keystone since keystone would populate the target dictionary
with user information, and possibly passwords.
This issue was found in keystone unit testing while trying to consume
oslo.policy 1.43.0.
Change-Id: I2702df8f3d7c040312eb863f7772b129e0e2c45c
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Mailinglists have been updated. Openstack-discuss replaces openstack-dev.
Change-Id: I84f738109f098415496619df423db7778b2fdcf2
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit makes it easier for services to protect APIs meant for
domain-only operations. It does this by making "domain-scope" an
official scope type to check for during policy enforcement.
A good example of where this would be useful is protecting the user
API in keystone, since user's are technically owned by domains.
This commit bumps the version of oslo.context to 2.22.0, which also
has domain support.
Depends-On: https://review.openstack.org/#/c/613635/
Change-Id: Ifc83a5f261bc823060eca5c4d0a4bf07966794c4
|
| |\ \ \
| |_|/
|/| | |
|
