Commit Graph

7 Commits

Author SHA1 Message Date
Takashi Kajinami d85a3ad38c Bump hacking
hacking 3.0.x is too old.

Change-Id: I3c40ded7174691473e4ce36eb37da73707178f3c
2024-01-26 01:12:45 +09:00
Hervé Beraud 2245235ece drop use of six
Change-Id: I40bb06d1d445d8eb8281f421a94d7dead2a89872
2020-03-02 14:58:28 +01:00
John Garbutt 40ef2764a5 Add flat enforcer
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
2019-11-25 18:30:28 +00:00
Lance Bragstad c02c025a66 Add ksa connection logic
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>
2019-11-22 16:58:36 +00:00
wangxiyuan 2773ea9edd Add opts file
Added opts file

added [oslo_limit] group.

keystoneauth options and "endpoint_id" are in this group.

Change-Id: I31e8f7c9f97b7175a7580f720383228e6f355f9a
2018-09-06 14:38:39 +08:00
wangxiyuan 5e34861854 ADD i18n file
Change-Id: I178f3144bb1850c62bb2ad06e2e88cd7713af58d
2018-07-30 16:15:03 +08:00
wangxiyuan 69eb4440dc Init repo
This patch initialises the limit repo using oslo-cookiecutter
tools.

Change-Id: Iaf748223fee886d057f40384c080d4dcd7d3ab73
2018-05-17 18:06:06 +08:00