In Zed cycle, we have dropped the python 3.6/3.7[1] testing
and its support. Removing the py36 centos8 job as well as
updating the python classifier also to reflect the same.
[1] https://governance.openstack.org/tc/reference/runtimes/zed.html
Change-Id: I9b5f826863fd913241cb803ef479b890f74fbb6c
In zed cycle, OpenStack projects and oslo lib
has dropped the py3.6 and py3.7 support
- https://governance.openstack.org/tc/reference/runtimes/zed.html
I also decrepated oslo-log < 5.0.0, so we should bump oslo.log>=5.0.0.
Because of oslo.log>=5.0.0 depends on oslo.i18n>=3.20.0 as below, so we
also need to upgrade oslo.i18n.
The conflict is caused by:
The user requested oslo.i18n>=3.15.3
python-saharaclient 1.4.0 depends on oslo.i18n>=3.15.3
castellan 0.16.0 depends on oslo.i18n>=3.15.3
keystonemiddleware 4.17.0 depends on oslo.i18n!=3.15.2 and >=2.1.0
oslo-config 6.8.0 depends on oslo.i18n>=3.15.3
oslo-concurrency 3.26.0 depends on oslo.i18n>=3.15.3
oslo-db 6.0.0 depends on oslo.i18n>=3.15.3
oslo-log 5.0.0 depends on oslo.i18n>=3.20.0
The user requested (constraint) oslo-i18n==3.15.3
The conflict is caused by:
The user requested pbr!=2.1.0 and >=2.0.0
bashate 0.5.1 depends on pbr>=1.6
fixtures 3.0.0 depends on pbr>=0.11
stestr 1.0.0 depends on pbr!=2.1.0 and >=2.0.0
testresources 2.0.0 depends on pbr>=1.8
testtools 2.4.0 depends on pbr>=0.11
python-saharaclient 1.4.0 depends on pbr!=2.1.0 and >=2.0.0
castellan 0.16.0 depends on pbr!=2.1.0 and >=2.0.0
keystoneauth1 3.4.0 depends on pbr!=2.1.0 and >=2.0.0
keystonemiddleware 4.17.0 depends on pbr!=2.1.0 and >=2.0.0
oslo-concurrency 3.26.0 depends on pbr!=2.1.0 and >=2.0.0
oslo-context 2.22.0 depends on pbr!=2.1.0 and >=2.0.0
oslo-db 6.0.0 depends on pbr!=2.1.0 and >=2.0.0
oslo-i18n 3.20.0 depends on pbr!=2.1.0 and >=2.0.0
oslo-log 5.0.0 depends on pbr>=3.1.1
The user requested (constraint) pbr==2.0.0
The conflict is caused by:
The user requested oslo.serialization!=2.19.1 and >=2.18.0
python-saharaclient 1.4.0 depends on oslo.serialization!=2.19.1 and >=2.18.0
keystonemiddleware 4.17.0 depends on oslo.serialization!=2.19.1 and >=1.10.0
oslo-log 5.0.0 depends on oslo.serialization>=2.25.0
The user requested (constraint) oslo-serialization==2.18.0
Change-Id: I117657e9861a55a751522dba3e3b1e75a22f9711
As per the community goal of migrating the policy file
the format from JSON to YAML[1], we need to do two things:
1. Change the default value of '[oslo_policy] policy_file''
config option from 'policy.json' to 'policy.yaml' with
upgrade checks.
2. Deprecate the JSON formatted policy file on the project side
via warning in doc and releasenotes.
Also replace policy.json to policy.yaml ref from doc and tests.
[1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html
Change-Id: Ib2101f13171940857fe81f64dd9798dfe489743a
= six (and tox): the latest versions of tox (which are
compatible with newer virtualenv[1][2]) require a newer six.
[1] https://tox.readthedocs.io/en/latest/changelog.html#v3-14-4-2020-02-13
[2] https://github.com/tox-dev/tox/pull/1519
= alembic: A newer version is required by oslo-db 6.0.0.
= oslo.service: 1.24.0 (and before 1.31.0) capped eventlet to <0.21.0,
but eventlet>0.26.0 is now required.
= cryptography: paramiko 2.7.1 requires cryptography>=2.5.0
= oslo-messaging: bumped to 10.2.0
= greenlet: bumped to 0.4.16 to be compatible with py3.9
= warlock, amqp, pycodestyle: just drop those indirect dependencies
from l-c (and in fact pycodestyle is only a dependency of a linter
for testing).
Change-Id: I26bd73463a5da9ef947f287610b0a33b73062417
- use the the python3 guestfs bindings, not the old python2
(not availbale anymore on the newer systems);
- fix the compatibility with mysql 8, which unfortunately
removes the shortend for user creation + password setting;
- bump the values in lower-requirements.txt (also requirements.txt
and test-requirements.txt when needed) so they they work with
python 3.8 (inspired by other similar bumps).
Change-Id: Icaa3c008bbe179098244f7bb9d80790068430fe2
OpenStack is dropping the py2.7 support in ussuri cycle.
Make a few cleanups:
- Remove python 2.7 stanza from setup.py
- Add requires on python >= 3.6 to setup.cfg so that pypi and pip
know about the requirement
- Remove ancient pbr section from setup.cfg
- Update requirements
- Use newer openstackdocstheme and setup storyboard support for it
- Remove Babel as requirement, this is not needed here anymore.
Change-Id: I0fd6fbdcbe788b0dfc2b1e20989b0a19ceec59f5
This release of the Cinder client broke support for the v3
volume-transfer APIs unless microversion 3.55 or higher was requested.
Change-Id: Ic763c2b52501867aeee2b1d014ab1f9e9c84e145
Requirements:
- bandit 1.6.0 contains a regression in the handling of patterns.
A fix is in place in bandit master, but newer versions introduces
more checks so they are not working as well.
The version is excluded there because is not handled by global
requirements.
Remove the separate requirement file for bandit, because
bandit has been part of test-requirements.txt in the last 3 years.
There is noneed for a separate requirements file anymore.
Even more, the bandit tox environment could be probably removed.
- synchronize the requirements for sphinx and jsonschema with the
current values from the requirements repository to make
the requirements-check job happy.
Jobs:
- temporarily disable the scenario-py3 job until a new stestr
(>2.3.1) is tagged.
Change-Id: Ief8e392fcd2d66a73593abcfda06fc7dbe2e53a6
This commit adds the functionality of sahara-status CLI for performing
upgrade checks as part of the Stein cycle upgrade-checkers goal.
It only includes a sample check which must be replaced by real checks in
future.
Change-Id: Idcb8d9eaf689800812cf6087e9c5937058c89ea6
Story: 2003657
Task: 26152
The mimimum requirement of Flask was recently bumped to 1.0.2
(https://review.openstack.org/#/c/577534/) which means that
the requirements-check job used for the sahara gate
is failing with a requirement mismatch errors.
Change-Id: I0fc7e3e8a847917be0877f71128a603d258a85ea
* Create common module for managing S3 job binaries
* Add new dependency on botocore
* Use common S3 library to create S3 job binary type for EDP
* Use common S3 library to create S3 job binary retriever
* Support storing S3 secret key in Castellan
* Document new job binary type (and foreshadow the S3 data source type)
* Unit tests for new code
Change-Id: I6781203d802305446ba1418ed6999186db4dfe9b
Partially-Implements: bp sahara-support-s3
zhouxinyong