Update to hacking 3.0.

Change-Id: I688ac4aea53d783ff8ae585d42efd8acab067f85

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>

Update the minversion parameter to use the python -m pip to install
python packages:

https://tox.readthedocs.io/en/latest/changelog.html#id185

It's recommend to use this. Remove the useless install_command
parameter.

Change-Id: Ic5c0f747c8d579ce3369635b67cdbf2d134c175d

Change-Id: Ifde690d7e5f59fc95533bc97d513d6aa6c432599

Change-Id: I40bb06d1d445d8eb8281f421a94d7dead2a89872

For further reading:
http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012606.html

Change-Id: I44cb645bd118c17e1f067cb617dbce845dacd5c6

Change-Id: I1bda5a8ccc9df040bf88df6bf8f428b6502f4542

OpenStack is dropping the py2.7 support in Ussuri cycle.

Complete discussion & schedule can be found in
-
http://lists.openstack.org/pipermail/openstack-discuss/2019-October/010142.html
- https://etherpad.openstack.org/p/drop-python2-support

Ussuri Communtiy-wide goal:
https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html

Change-Id: Ie48c796b6c83b42c85555d13a09f3b3ed96428f8
Sem-Ver: api-break

move 'basepython' to the top-level 'testenv'

Change-Id: I197d6486a3b126f616ffe2f7e3e669d922a1e337

We know we want to have some level of functional testing to verify
enforcement models. This commit uses one approach to add a base
devstack job to oslo.limit's .zuul.conf so that we have a minimal-ish
installation to configure with limits and write actual integration and
functional tests against.

Change-Id: I50c41805b8e196fdaf20c95e9aa687b98c369a57

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&lt;lbragstad@gmail.com>
Co-Authored-By: wangxiyuan <wangxiyuan@huawei.com>

Change-Id: I294a922ea80af673291c991f07a4a203f25c289d

For a given resource find out the current limits for the project.
If there are no per project limits look up the registered limits
that act as a default for when there are no project limits.

Future patches will look at comparing these limits with the current and
proposed resource usage to enforce the limits.

Change-Id: Ia5ced4a46833b194f397ac936b99b0c9573b50d1
Co-Authored-By: wangxiyuan <wangxiyuan1007@gmail.com>
Co-Authored-By: Lance Bragstad <lbragstad@gmail.com>

The enforcer needs to be able to determine which model to use and pass
information to it. This commit sets the model attribute on the
enforcer, adds a method to determine which model to use, and
defines a basic interface for enforcement models to use.

Change-Id: Id03d361b702c2ee0811f37ad23bb2b9a3171b1f7
Co-Authored-By: wangxiyuan <wangxiyuan1007@gmail.com>
Co-Authored-By: Lance Bragstad <lbragstad@gmail.com>
Co-Authored-By: John Garbutt <john.garbutt@stackhpc.com>

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

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: I07dc249c5fdd264c40407b4d1e9fd3b0ea40f43c
Sem-Ver: feature

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: I78d3a9c14f54dd38d834f99a33c41494fa22255b
Story: #2005924
Task: #34234

filter_resources doesn't make as much sense as resource_filters.
filter_resources almost sounds like a boolean, when the argument is
designed to contain a list of strings that represent resources to
filter.

Change-Id: Idc787052ac41744075d4a4860d06a3529fd271bb

The `enforce()` method is going to be the main entry point into
oslo.limit for services enforcing usage against unified limits.

Future patches will add methods for collecting information from
keystone, resolving callback functions for project resource usage, and
implement different enforcement models (flat, strict-two-level).

Change-Id: I3cca109213e6d3fad91160ebb632d15499690093

Originally, we wanted oslo.limit's Enforcer object to be a context
manager to make it easier to abstract logic to protect against
resource race conditions. Since verification logic isn't going to be
implemented right away, we can just focus on a single method for
enforcement instead, making it easier to adopt.

Subsequent patches are going to introduce a new enforcement interface
for oslo.limit.

Change-Id: I3a1e58cb18a498bca67f36c76d8e8c8c4fb80083

We want the initial implementation of oslo.limit to be as simple as
possible. Originally, we thought we were going to implement resource
verification, but that's something we can do later.

Resource verification is meant to protect against race conditions when
two clients claim the same amount of resources and the project is over
limit. Unfortunately, having services implement resource verification
requires them to use either a context manager or make multiple calls
to enforce limits and sprinkling those calls around existing business
logic. Since we don't know which approach we want to use to implement
this, let's just focus on enforcing limits and come back to resource
verification when we get more feedback from developers incorporating
this into their services.

Change-Id: I50f52189862bc3d109654e158cba381b156e70b6

The concept of having project claims and tacking them on to an
Enforcer object is too heavy-handed for what we need right now.
Instead, we can just use a dictionary with resource names as the key
and their respective usage/request limits as values.

Future patches will remove the context manager functionality from
oslo.limit, too. We can revisit the concept of a context manager to
implement additional functionality for verification and race
conditions when we have a for sure need for it.

The goal of this patch is to make the interface as simple as possible
so that it is easier for projects to adopt it.

Note: we're able to make these changes because we haven't released
oslo.limit, yet. We can make breaking changes up to version 1.0, so we
can easily come back to this approach up to that point.

Change-Id: I3f04ffc6d27208500b8e6409c3c30e6cb3147169

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

Change-Id: Ibb5a0f72dd8e7dab4c42340f26226fdc6451d523

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.

In Train, we will use python3.6 and 3.7 for
which the minimum tox version required is 2.5[1]

[1]https://tox.readthedocs.io/en/latest/changelog.html#v2-6-0-2017-02-04

Change-Id: I6bea49746a9a262fe9b7346909418e35dad6a12c

Python 3.5 was the target runtime for the Rocky release.
The current target py3 runtime for Stein is Python 3.6,
so there is no reason to keep testing against the older version.

https://governance.openstack.org/tc/reference/runtimes/stein.html#python-runtime-for-stein

Change-Id: Id4cb74fcbb011bd80f82c0cad907b6eea9c47f1a

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: I51c76a0515e80de590da9d511dfd51f82153a72e

This is a mechanically generated patch to add a unit test job running
under Python 3.7.

python3.5 was the only supported python3 version on Xenial. Now that
we have Bionic nodes supporting python3.6 and python3.7, let's add
testing with python3.7 in addition to python3.6 in Stein and
beyond.

See ML discussion here [1] for context.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135626.html

Change-Id: Id0d0a55f4ceaa05869cb77abf13ee2fea7bee713
Story: #2004073
Task: #27440

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: I1d611881854dd203064e99962fb8d3fe02940958

Use latest release 1.1.0 and compatible changes w.r.t pep8

Change-Id: I7a3627314d93342604c561dc7973d394a21c4e3c

Change-Id: Iabeffef5c11aa2a7ef65fbd86a995a08176009dd