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
flake8 new release 3.8.0 added new checks and gate pep8
job start failing. hacking 3.0.1 fix the pinning of flake8 to
avoid bringing in a new version with new checks.
Though it is fixed in latest hacking but 2.0 and 3.0 has cap for
flake8 as <4.0.0 which mean flake8 new version 3.9.0 can also
break the pep8 job if new check are added.
To avoid similar gate break in future, we need to bump the hacking min
version.
- http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014828.html
Change-Id: I70ca30dd0a5bf0f1aa44f627d92038c826b67174
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 patch bumps bandit allowed version to >=1.6.0,<1.7.0 in order to
avoid the errors detailed here https://github.com/PyCQA/bandit/pull/393
Change-Id: I568123c93c32cb224628c4a8371a9a0e7c19cf67
Signed-off-by: Moisés Guimarães de Medeiros <moguimar@redhat.com>
The repo is Python 3 now, so update hacking to version 2.0 which
supports Python 3.
Blacklist: W504 line break after binary operator
Change-Id: I7ca780a2cff32031c562482b804888e5d49712c1
Now that we no longer support py27, we can use the standard library
unittest.mock module instead of the third party mock lib.
Change-Id: I0d2b84e2ed627481118151b36386014ed0930452
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Taking the Nova work as an example, looking to add a basic flat enforcer
that meets Nova's needs.
The user of the Enforce provides a callback. You can see an example of
the callback in the unit tests:
def fake_callback(project_id, resources):
return {
"a": 5,
"b": 10,
"c": 0,
}
In the code where you want to check if you increase the amount of
resources that are being consumed, you can make this call:
enforcer = limit.Enforcer(fake_callback)
enforcer.enforce(project_id, {"a": 5})
The enforce function looks up the limits that apply for the given
project_id, uses the callback to count the current usage. The proposed
usage is then calculated be adding the delta and the current usage
together. This is compared to any limits that apply.
If you later want to check if you have races that mean you are
over your limit, you can do this call:
enforcer.enforce(project_id, {'a': 0})
Summary of key design points:
* single set of logic to enforce limits shared between all projects
that adopt unified limits
* interface should work for both flat and strict-two-level enforcement
* it is assumed that oslo.limit will control which type of enforcement
is being applied
* callback lists all resources that need counting
for the given project_id, in Nova this helps limit
the number of API calls made to placement
* allows to check if proposed additional usage means you are over
your limit, and also double check if the current usages means
you are over quota
* if the code is checking a resource where you do not have a
registered limit, we default to a limit of zero, i.e. no
resources can be created unless you set that registered limit
There will be an appropriate warning logged to help the operator
understand what needs to be setup in keystone.
This builds on various previous prototypes from:
Co-Authored-By: Lance Bragstad<lbragstad@gmail.com>
Co-Authored-By: wangxiyuan <wangxiyuan@huawei.com>
Change-Id: I294a922ea80af673291c991f07a4a203f25c289d