This patch is the merge of 2 current fixes that need to be solved in the
same time. Indeed each issue lock our gates independently.
Dropping lower constraints testing
We facing errors related to the new pip resolver, this
topic was discussed on the ML and QA team proposed to
to test lower-constraints [1].
I propose to drop this test because the complexity and recurring pain needed
to maintain that now exceeds the benefits provided by this mechanismes.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-December/019390.html
Move flake8 as a pre-commit local target.
The goal here is to avoid conflicts between flake8 and hacking version each
2 days.
Inspired from nova's approach[1].
The flake8 version to install will be determined by hacking and
requirements[2] will stay aligned instead of relying on different versions.
[1] https://opendev.org/openstack/nova/src/branch/master/.pre-commit-config.yaml#L26-L35
[2] https://opendev.org/openstack/hacking/src/branch/master/requirements.txt#L1
Co-authored-by: Daniel Bengtsson <dbengt@redhat.com>
Change-Id: I04a845fd98f0d21f7a21dae9f184117263390dd1
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
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
This commit pulls the ksa-specific logic from a previous attempt:
Ibc35360dd4a952bbe63ee68ddafd5def0608949d
Subsequent patches will use this connection to query unified limit
information out of keystone.
Change-Id: Iae45df091e98904fd6a30db9923b141279fb2cc0
Co-Authored-By: wangxiyuan <wangxiyuan1007@gmail.com>
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
Added opts file
added [oslo_limit] group.
keystoneauth options and "endpoint_id" are in this group.
Change-Id: I31e8f7c9f97b7175a7580f720383228e6f355f9a
Hervé Beraud