The calculate_usage interface was added recently to allow consumers
to probe limits and usage without requiring the enforce behavior
workflow. If a limit was passed to it that was not registered in
keystone, get_project_limits() would raise a ProjectOverLimit
exception itself to abort the process immediately, providing the
"unregistered means zero" behavior. This works fine for the enforce
workflow, but not the calculate one.
This changes get_project_limits() to just return a zero limit for
a missing one, which will be considered by the enforce workflow in
the same way, keeping the existing behavior. It will merely be
reported by the calculate workflow, which is the desired change.
Change-Id: Iaab1f0d5eb0da9a667267537d86f6c70bc8db51d
This adds a fixture that can be used by consuming projects to
simulate a set of limits in keystone, without requiring actual
keystone. Currently, consumers have to mock oslo.limit internals (at
least) in order to do testing.
Change-Id: If72050e90ca8b03e26d128c7bbcef6bbea92b501
In multiple situations, it is necessary to be able to probe the limits
set for a project without actually enforcing. Examples:
1. Exposing a usage API where we want to not only report the current
usage, but the limit as well. Otherwise clients have to do their
own calls to keystone and correlation to get a single integer
limit value, which we should be able to expose for them.
2. When checking quota as part of a long-running process of consuming
an unbounded data stream, we need to be able to determine how much
quota remains so that we can stop the transfer if we exceed the
limit. Without this, we have to periodically call to keystone
during the transfer, which is expensive and could fail.
This patch adds a calculate_usage() method to the Enforcer which
calculates the usage using the enforcement model and returns a
mapping of resource names to namedtuples that contain limit and usage
information.
Change-Id: Ic0632cc5ec52aefb85a04f879651963bfa54dcbe
Introduced changes:
- pre-commit config and rules.
- Add pre-commit to pep8 gate, Flake8 is covered in the pre-commit hooks.
- Applying fixes for pre-commit compliance in all code.
Also commit hash will be used instead of version tags in pre-commit to
prevend arbitrary code from running in developer's machines.
pre-commit will be used to:
- trailing whitespace;
- Replaces or checks mixed line ending (mixed-line-ending);
- Forbid files which have a UTF-8 byte-order marker
(check-byte-order-marker);
- Checks that non-binary executables have a proper
shebang (check-executables-have-shebangs);
- Check for files that contain merge conflict strings
(check-merge-conflict);
- Check for debugger imports and py37+ breakpoint()
calls in python source (debug-statements);
- Attempts to load all yaml files to verify syntax (check-yaml);
- Run flake8 checks (flake8) (local)
For further details about tests please refer to:
https://github.com/pre-commit/pre-commit-hooks
Change-Id: Ic00da1340d695c7a109f41a09929b654baf995a7
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
This commit add a new user guide about how a service
developer can easily integrate oslo_limit and use
Keystone unified limit system.
Change-Id: I415fdef757e5f78f1c201c32489bc00a1f3cebd0
Switch to openstackdocstheme 2.2.1 and reno 3.1.0 versions. Using
these versions will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Remove doc requirments from lower-constraints, they are not used for
install. Remove also hacking, the version is ancient and not needed
there either.
openstackdocstheme renames some variables, so follow the renames. A
couple of variables are also not needed anymore, remove them.
Set openstackdocs_auto_name to use project as name.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: I5ec9dda8582f55fc0b287c422d5c43ad2e23b9b8
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: Ib1749e690c22663955985f0c3b718ed6223be223
Sync sphinx dependency with global requirements. It caps python 2 since
sphinx 2.0 no longer supports Python 2.7.
Change-Id: I676fdc12fe0bb1278754d6f21c6a113b4182186f
Closes-Bug: #1831406
As a result, this commit message is guaranteed to have a grammar or
spelling error.[1] ;-)
Change-Id: Ie941d36a7e3d7918a18dc71735307451835d3038
1: https://en.wikipedia.org/wiki/Muphry%27s_law
Let's be consistent with the rest of the oslo libraries and use the
openstack docs theme for documentation.
Change-Id: Ie496a5540e4ede74faba89b268d4ec00f8182add
Most of the documentation describing the intent of this system
is scattered across specifications. This commit attempt to level-set
some basic terminology from the perspective of someone looking to
use this library.
Change-Id: I45c5f2f2747e548ca094172871f91ce0d74d77ac
Now that we're starting to commit code to the repository
and build out an API, we should start generating documentation for
it.
Change-Id: I20e9d3155331c08cc3817c17c183e80a89235b7f
Fix documentation build by correcting a source filename and fixing
the dependency settings.
Change-Id: I1fc098cef7097ffea338129a3fcefda77f396a3a
Signed-off-by: Doug Hellmann <doug@doughellmann.com>