This version broke the behavior of strict_slashes=False that
ironic-inspector relies on. See this bug:
https://github.com/pallets/werkzeug/issues/2467
The newly released 2.2.1 fixes it, jump straight to it.
Change-Id: I7e718345c9ec220c82689de56d367773d8e19a0b
This release has a patch [1] that seems to introduce an issue
without the needed Neutron logic.
[1]75b290fb2a
Related-Bug: #1940425
Change-Id: Ie77f935a79d8681d133833e2ccbea6140c625cb2
warlock recently had a 2.0.0 release that added support for jsonschema
4.x [1]. We no longer need to cap this.
[1] https://github.com/bcwaldon/warlock/releases/tag/2.0.0
Change-Id: I43559379bc71c990361af24b5e2543b426ce84da
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
networkx release 2.8.4 has a bug [0] that affects the Octavia doc job
(via Taskflow), skip this version.
[0] https://github.com/networkx/networkx/issues/5790
Change-Id: Ie800f4856248c39f7cc70f094097b350baa078c2
importlib-metadata is a rolling backport of importlib.metadata from
stdlib. Some people might want to use it to take advantage of new
functionality [1]. We shouldn't prevent them doing so. This is very
similar to what lifeless for the mock library - itself a rolling
backport - in change Iff09ab8c5ee4c2f0cf88596f084d6b5b340be8d8.
[1] https://pypi.org/project/importlib-metadata/#compatibility
Change-Id: I5febaed02e95ff27accd946abc32f3bcbb1a5ead
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
This reverts commit 05996e009c.
Reason for revert:
From what I can tell, instead of allowing you to use either PrettyTable or prettytable in your requirements.txt, it forces you to use *both*, which is completely contrary to the intention of this patch. See the commit message on https://review.opendev.org/c/openstack/glance/+/843143 for how I came to this conclusion.
The patch that the original change was Needed-By never merged (it failed the requirements-check job).
Being required to use both PrettyTable *and* prettytable in requirements.txt is probably a bug in the requirements checking code, but that shouldn't stop us from reverting this patch.
Change-Id: Id65e566b8f943cf60d4f2b646e88876c4ababbd4
This change adds the ncclient, a python library for NETCONF
clients.
Active: yes
Good code: yes
python3: yes, Python 3.4+, upstream CI checks on:
3.5, 3.6, 3.7, 3.8, 3.9
License compatible: yes
Packaged: yes, Ubuntu and Fedora.
Covered by other libs: no
Needed by: networking-baremetal (https://review.opendev.org/835324)
Managed by openstack: no
Story: 2009961
Task: 44999
Change-Id: I82d6d0d0af9335ff08a223c449d4d1db5b3a9fac
The dnspython 2.2.0 release has a confirmed bug[1] that breaks designate by
improperly parsing zone files.
This patch blocks version 2.2.0, moving UC back to 2.1.0, so that test
jobs will pass again while we wait for a new release of dnspython.
[1] https://github.com/rthalley/dnspython/issues/766
Change-Id: Idc906d4e22d98d295d261a7a32def22f5f24c294
The TripleO team discussed and agreed to move forward with adding task-core to
TripleO at the last PTG:
https://etherpad.opendev.org/p/tripleo-directord-task-core
* Is the library actively maintained?
Yes, it is actively maintained by the TripleO community at
https://github.com/directord/task-core
* Is the library good code?
Yes, as the authors, we'd like to think so.
* Is the library python 3 compatible?
Yes. There are python3 jobs setup on Github.
* Is the library license compatible?
Yes. It is licensed Apache 2.0.
* Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
Not yet, but we are in the process of packaging it in RDO:
https://bugzilla.redhat.com/show_bug.cgi?id=2021983
* Is the function of this library already covered by other libraries in global-requirements.txt?
No.
* Is the library required for OpenStack project or related dev or infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes. TripleO.
The first patch that would require task-core is:
https://review.opendev.org/c/openstack/python-tripleoclient/+/821624
If the library release is managed by the Openstack release process does it use the cycle-with-intermediary release type?
It is not yet managed by the OpenStack release process, but may be in the future.
Do I need to update anything else?
No.
Signed-off-by: James Slagle <jslagle@redhat.com>
Change-Id: Ia7b92d62abdedcb6222cef4159d9edecdf65e0e0
directord is a task execution engine for TripleO.
The TripleO team discussed and agreed to move forward with adding directord to TripleO at the last PTG:
https://etherpad.opendev.org/p/tripleo-directord-task-core
* Is the library actively maintained?
Yes, it is actively maintained by the TripleO community at
https://github.com/directord/directord.
* Is the library good code?
Yes, as the authors, we'd like to think so.
* Is the library python 3 compatible?
Yes. There are python3 jobs setup on Github.
* Is the library license compatible?
Yes. It is licensed Apache 2.0.
* Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
Not yet, but we are in the process of packaging it in RDO:
https://bugzilla.redhat.com/show_bug.cgi?id=2021967
* Is the function of this library already covered by other libraries in global-requirements.txt?
No.
* Is the library required for OpenStack project or related dev or infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes. TripleO.
The first patch that would require directord is:
https://review.opendev.org/c/openstack/python-tripleoclient/+/822703
If the library release is managed by the Openstack release process does it use the cycle-with-intermediary release type?
It is not yet managed by the OpenStack release process, but may be in the future.
Do I need to update anything else?
No.
Signed-off-by: James Slagle <jslagle@redhat.com>
Change-Id: I8ab15fe1300743a43384be9e7a1c8f8159a73cc9
PrettyTable package is an old naming of prettytable.
Currently prettytable and PrettyTable resolve to the same package
in pypi and both names work.
As a result, when installed it's shown as prettytable.
This patch aims to allow developers to add prettytable package to
their project requirements and not have to reffer to the old naming.
Needed-By: https://review.opendev.org/c/openstack/openstack-ansible/+/777061
Change-Id: I75a025d3c347cc895328949281b8068b7af85a6c
This patch partially revert 7816293.
horizon selenium-headless and integration-tests job start failing
after updating selenium version 3.141.0 -> 4.1.0. So let's use
selenium older version until we fixed the failed gate job with new
selenium version. It also cap selenium version < 4.0.0 in
global-requirements.txt
Related bug: 1947847
Change-Id: I7856509e792c6114807c7b1c88ac4d65afc27706
redis 4.0.0 triggers some errors when enabling jobboard in taskflow, the
issue was fixed in [0] which is included in 4.0.1
[0] https://github.com/redis/redis-py/commit/\
4e9cc015e32ef305429ff9dfa200e28dd63e6663
Change-Id: I59baffed7717a2f0859297206f88f1ca28a5129f
This patch update Django version to the current LTS version i.e. 3.2
in global-requirements.txt as Django 2.2 is going to end its extended
support by April 2022[1]. horizon and all its plugins already support
Django 3.2 version, So let's make this the default version. Also,
I will update the Django version in ``upper-constraints.txt' in a
separate patch because if I update the Django version in
upper-constraints.txt in the same patch requirements check-uc job
starts failing.
[1] https://www.djangoproject.com/download/
Change-Id: I600d36a842ef56dfb01d932df079a32e7f7395e4
This patch partially revert Id1e12179980ad4eb64b8de6fcc1280698bbb2661.
horizon selenium-headless and integration-tests job start failing
after updating selenium version 3.141.0 -> 4.0.0. So let's use
selenium older version until we fixed the failed gate job with new
selenium version.
Related bug: 1947847
Change-Id: I461ab4189fb652c78bc11d0a9283d98948c2725c
suds-community will replace suds-jurko after we remove all dependencies
to the suds-jurko.
Change-Id: I4eb235c3ad0f1296fc81a9b98d7e687ac9923b59
Signed-off-by: Matthew Thode <mthode@mthode.org>
The python-ceilometerclient project was EOLd a number of a cycles ago
after no activity for some four years. Remove python-ceilometer from our
global requirements so we don't test compatibility with it any more.
Change-Id: I80ef7d9a20e007b6db965b37113870ce8a5a68c4
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The Glare project was removed from governance and has not had any
activity for three years. This removes python-glareclient from our
global requirements so we don't test compatibility with it any more.
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Change-Id: Iea0d6e0389a488d6a8a83a6810e06e8f22664e01
The fix was merged some time ago and appears to be stable.
Furthermore, versions 1.2.0 and higher introduce number of
important fixes and changes that are now being left out.
This reverts commit 960c753013.
Signed-off-by: Jiri Podivin <jpodivin@redhat.com>
Change-Id: Id32adfcf27cd48a179dbacced47b2990fcf628e6
autopage is a library for automatically invoking 'less' when needed in
command-line programs and piping the output through it. It is wanted to
improve the user experience of python-openstackclient and other
cliff-based command line tools.
Review questions:
* Is the library actively maintained?
Yes (by me).
* Is the library good code?
I wrote it, so I'd like to think so. I've been testing it out in one of
my own projects in a lot of different scenarios, and I believe it has
got to the point where it is very robust.
* Is the library python 3 compatible?
Yes (requires Python 3.6 or later).
* Is the library license compatible?
Yes, Apache 2.0 license.
* Is the library already packaged in the distros we target (Ubuntu
latest / Fedora latest)?
No, but the necessary packaging files are available upstream, and distro
packages for Fedora/CentOS and Ubuntu are available in Copr and PPA,
respectively:
https://copr.fedorainfracloud.org/coprs/zaneb/autopage/packages/https://launchpad.net/~zaneb/+archive/ubuntu/autopage
* Is the function of this library already covered by other libraries in
global-requirements.txt?
Not that I know of.
* Is the library required for OpenStack project or related dev or
infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes, of course.
https://review.opendev.org/c/openstack/cliff/+/799344https://review.opendev.org/c/openstack/cliff/+/799345
* If the library release is managed by the Openstack release process
does it use the cycle-with-intermediary release type?
N/A
* Do I need to update anything else?
No, there are no transitive dependencies.
Change-Id: Ic773519e5ab3e940cb23a96b99295f7eb8986691
While developing a new feature in CloudKitty, we adopt a library
(datetimerange) to facilitate the handling/processing of
datetime ranges. Therefore, to make the Zuul requirements check
happy, we are introducing this new dependency into the global
requirements file.
Add datetimerange library to global requirements
While developing a new feature in CloudKitty, we adopt a library
(datetimerange) to facilitate the handling/processing of
datetime ranges. Therefore, to make the Zuul requirements check
happy, we are introducing this new dependency into the global
requirements file.
Here follows the answers to the new library requirement questions:
1 - Is the library actively maintained?
Yes, it is. As we see in [1], the component has more or less one
yearly release. It is a very focused library, so this release process
makes sense.
2 - Is the library good code?
Yes, it is. As we can see in [2], it has a 95% of code coverage.
Moreover, while navigating in the code repository, we can see that
methods are well documented, and coded.
3 - Is the library python 3 compatible?
Yes, it is. That is also found in the README of the project in [2].
4 - Is the library license compatible?
According to reference [3]:
```
In order to be acceptable as dependencies of OpenStack projects,
external libraries (produced and published by 3rd-party developers)
must be licensed under an OSI-approved license that does not restrict
distribution of the consuming project. The list of acceptable licenses
includes ASLv2, BSD (both forms), MIT, PSF, LGPL, ISC, and MPL.
Licenses considered incompatible with this requirement include GPLv2,
GPLv3, and AGPL.
```
Therefore, the project fits nicely into these requirements. The project
in question is licensed under MIT, as we can see in [2], in the right
corner part of the page, and also in the LICENSE file at the root of
the project.
5 - Is the library already packaged in the distros we target (Ubuntu
latest / Fedora latest)?
It is installed via PIP; PIP is available in major distros. Therefore,
it is possible to use this library in all of them by issues the command
`pip install DateTimeRange`.
6 - Is the function of this library already covered by other libraries
in global-requirements.txt?
No. At least, I did not find it.
7 - Is the library required for OpenStack project or related dev or
infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes, it is. We have a new feature being developed ion Cloudkitty in
[4], which needs this library to handle DateTime ranges.
8 - If the library release is managed by the Openstack release process
does it use the cycle-with-intermediary release type?
It is not managed by the OpenStack release process.
9 - Do I need to update anything else?
No.
[1] https://github.com/thombashi/DateTimeRange/releases
[2] https://github.com/thombashi/DateTimeRange
[3] https://governance.openstack.org/tc/reference/licensing.html
[4] https://review.opendev.org/c/openstack/cloudkitty/+/799207
Change-Id: I608331e28ef349399068f9b1fa16bd6a6c5779e6
This is the split out type hints for paramiko from typeshed [1]. It's
necessary for nova to avoid the following issue:
error: Library stubs not installed for "paramiko" (or incompatible with Python 3.9)
note: Hint: "python3 -m pip install types-paramiko"
note: (or run "mypy --install-types" to install all missing stub packages)
note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
This can be resolved by installing the hints package, as the error
suggests.
* Is the library actively maintained?
Yes. It's part of typeshed [1].
* Is the library good code?
Yes.
* Is the library python 3 compatible?
Yes.
* Is the library license compatible?
Yes - Apache 2.0.
* Is the library already packaged in the distros we target?
No.
* Is the function of this library already covered by other libraries
in global-requirements.txt?
No.
* Is the library required for OpenStack project or related dev or
infrastructure setup?
Yes. It's required by nova, which uses paramiko and type hints.
[1] https://github.com/python/typeshed
Change-Id: I9437e48ad382c6e04a37bfe2448ad1299e72d1af
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This Python library is now a requirement for building
documentation (ansible-autodoc) for the following project:
- openstack/tripleo-validations
- openstack/validations-common
ruamel.yaml is a YAML 1.2 loader/dumper package for Python.
The library is actively maintained, with almost a weekly release. It is
compatible with Python 2 and 3 and licensed under the MIT.
https://pypi.org/project/ruamel.yaml/
Signed-off-by: Gael Chamoulaud (Strider) <gchamoul@redhat.com>
Change-Id: I208b00629493953a502f8b95756820ae0d9a9cb6
As described in [1], since #844 was introduced, when a table is
created, all columns "index" and "unique" flags are unset.
In 1.6.4 [2], "CreateTableOp" sets the flag
"_constraints_included" to False by default. That will honor
the "index" and "unique" flags set in each column definition.
Related-Bug: #1929518
[1]https://github.com/sqlalchemy/alembic/issues/848
[2]https://gerrit.sqlalchemy.org/c/sqlalchemy/alembic/+/2839
Change-Id: I90380b027cade633088099ae766ff5c116014cea
This reverts commit 7e30166d07.
Reason for revert: This was pushed out of order, apologies. We'll need to remove some of the tripleo repos from projects.txt first.
Change-Id: I4dc6f68fabdab8be21e47135473bd61134aa0717
As of Wallaby, TripleO no longer requires Mistral for deployment. The
only other projects relying on tripleo-common are within the TripleO
project itself and those projects are not in global-requirements. As
such, tripleo-common can be removed as there are no dependencies with
any other non-TripleO OpenStack deliverables.
Signed-off-by: James Slagle <jslagle@redhat.com>
Change-Id: I1ef4aead6a554448ec9c557961f8391d6493ab87
python-linstor is a pure python library for accessing the Linstor API.
It is in use by the Linstor driver in the Cinder project.
The library is actively maintained, with new releases on every new Linstor
release. It is compatible with Python 2 and 3, and since release 1.7.0
licensed under the LGPLv3.
Change-Id: Icfe13df75440eeaf6f5b1601f629c3230b119bb2
pycdlib is a pure python library used to parse,
read and write ISO9660 files. With LGPLv2 as the
license it confirms to openstack licensing guidelines.
This is an actively maintained library. As of this
writing the last change to this library was 8 days
ago and the first commit was over 6 years ago.
This library is compatible with python3
https://clalancette.github.io/pycdlib/python-compatibility.html
It is a well documented library and the documentation
is available at https://clalancette.github.io/pycdlib
This library will be used by ironic to read config
drive and write them to disk on the filesystem.
Change-Id: Idfb40ba12893d75731542044d79532ee27c2a499
It's the one py2-specific dependency that python-swiftclient needs; keep
it around so the Swift team can still modify their requirements files.
Change-Id: Icb055e7a9d48e1e48126ef2692f796c4dc11f8b1
Needed-By: https://review.opendev.org/#/c/776998
Related-Change: I1bc1fe988e3cfd4824dd7b4a9327a67db46c1533
Related-Change: I704979556369dc244da51608a13abc5a06a29912
PrettyTable was capped at a < 0.8, which meant we were getting the
veritably ancient 0.7.2 release first release in April 2013 (!) [1].
The project is now being maintained as a Jazzband project [2], meaning
we can remove the cap. The API is pretty much unchanged so this should
have little impact for projects that depend on this library.
[1] https://pypi.org/project/prettytable/#history
[2] https://github.com/jazzband/prettytable
Change-Id: I42d2fe96cd81d8c159f54dc10a18bf6bfebf601f
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
This patch revert I601a59260daeb925fbd23e8c4e006df733ec6528 commit.
After updating XStatic-JQuery-Migrate to 3.3.2.1 horizon integration
tests start failing. As discussed in yesterday's horizon weekly
meeting[1] horizon team decided to use the older version of
xstatic-jquery-migrate until we fixed the integration tests with the
new xstatic-jquery-migrate version.
It also raise cap on XStatic-JQuery-Migrate version.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2021-02-03.log.html#t2021-02-03T15:43:44
Change-Id: I617e3b73d93792ce23a3c2427db45764dac85498
Dmitry Tantsur
Rodolfo Alonso Hernandez
Gregory Thiemonge
Stephen Finucane
Dr. Jens Harbott
Hervé Beraud
Matthias Runge
Matthew Thode
OpenStack Proposal Bot
Brian Rosmaita
Harald Jensås
Michael Johnson
Takashi Kajinami
yatinkarel
James Slagle
Dmitriy Rabotyagov
manchandavishal
Josephine Seifert
Federico Ressi
Gunju Kim
Sean McGinnis
Jiri Podivin
Zane Bitter
Rafael Weingärtner
Stephen Finucane
Gael Chamoulaud (Strider)
Moritz "WanzenBug" Wanzenböck
Arun S A G
Tim Burke
Ghanshyam Mann
Akihiro Motoki