delta/openstack/python-troveclient.git/tox.ini, branch stable/queens

Update UPPER_CONSTRAINTS_FILE for stable/queens

2018-02-01T17:45:03+00:00

Change-Id: I030d873b568eaf871e1b9fab711909e67095f235

Avoid tox_install.sh for constraints support

2017-12-02T16:54:12+00:00

We do not need tox_install.sh, pip can handle constraints itself
and install the project correctly. Thus update tox.ini and remove
the now obsolete tools/tox_install.sh file.

This follows https://review.openstack.org/#/c/508061 to remove
tools/tox_install.sh.

Change-Id: I65e1e4d40fbd56c7e2f7e4a59c0438d7176c36b4

Handle log message interpolation by the logger

2017-03-08T18:00:34+00:00

According to OpenStack Guideline[1], logged string message should be
interpolated by the logger.

Also, upgraded hacking requirement, to enable H904 check.

[1]: http://docs.openstack.org/developer/oslo.i18n/guidelines.html#adding-variables-to-log-messages

Co-Authored-By: jiansong 
Change-Id: I3f020b6bcb1b9bf6d18a3b4f738c13cccd1bbff8
Closes-Bug: #1596829

Get python-troveclient to use upper-constraints.txt

2016-11-17T03:38:20+00:00

In review[1] which passed just fine in check some days ago failed in
gate today. This is because the current tox environment uses requests
v2.12.1 which appears to not work and is beyond the value in
upper-constraints.txt. As observed in [2] we need
upper-constraints.txt in python-troveclient.

But since python-troveclient is itself listed in upper-constraints.txt
you can't just stick it in tox.ini and expect good things to happen.

I'm adding a co-author to this change based on [2].

[1] https://review.openstack.org/#/c/382493/
[2] https://review.openstack.org/#/c/398339/

Co-Authored-By: jiansong 
Change-Id: I386efb2d5c147417af7ea25704405977c9b6bbcd

Merge "Remove times.dbm file for each tox run"

2016-04-14T17:00:27+00:00

Add reno for release notes management

2016-04-08T00:45:49+00:00

Add reno to generate release notes for the Trove client.

Change-Id: I8e475e1148ec32f9beb3398ecbb5effccd7ea4fb

Remove times.dbm file for each tox run

2016-04-04T18:12:44+00:00

If you run the py27 tox tests then attempt to run the py34 tests,
the following error will occur:

    running testr
    running=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
    OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
    OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
    ${PYTHON:-python} -m subunit.run discover -t ./ ./ --list
    db type could not be determined
    error: testr failed (3)

This happens because the apparently the times.dbm file generated
by py27 is not compatible with py34. The converse is not true though -
if you run py34 first, py27 will work.

Both these bugs have been filed against it, but I see no resolution
https://bugs.launchpad.net/testrepository/+bug/1212909
https://bugs.launchpad.net/testrepository/+bug/1229445

The work-around is to delete the file, which is what is now done
before running every tox test. Once the bug has been fixed, the
work-around can be removed.

Change-Id: Icf5d9efc65ffda8acdcc6f43b37ef03c84b3fd43
Closes-Bug: #1565928

use oslotest to break into the debugger when running test cases

2016-01-21T12:57:03+00:00

Once we add debug testenv, we can use "tox -e debug" to debug test cases
when tox is running. Then tox will use oslotest which really debug our
test cases.

Only we should do is insert pdb into code.It's easy to use.

The same in trove:
https://review.openstack.org/#/c/265524/

usage link:
http://docs.openstack.org/developer/oslotest/features.html

Change-Id: I93709451af9a14fc9c71e1c3306a1a025aee8b44

Put py34 first in the env order of tox

2016-01-07T02:53:03+00:00

To solve the problem of "db type could
not be determined" on py34 we have to run first the py34 env to, then,
run py27. This patch puts py34 first on the tox.ini list of envs to
avoid this problem to happen.

Change-Id: I90be329de961a0a63607d04b5c7cc88d033f05ec
Closes-bug: #1489059

Drop py33 support

2016-01-05T07:10:03+00:00

"Python 3.3 support is being dropped since OpenStack Liberty."
written in following URL.
https://wiki.openstack.org/wiki/Python3

And already the infra team and the oslo team are dropping py33
support from their projects.

Since we rely on oslo for a lot of our work, and depend on infra
for our CI, we should drop py33 support too.

Change-Id: I37a08fc005ec78031e582721a5e472348ee5324c
Closes-Bug: #1526170