Rely on our ability to compute a good lower constraints set for
multiple projects using the build-lower-constraints command instead of
maintaining a single list in this repository.
Change-Id: I0a4be42efdbfd73228d043c1aa21feb7829650f3
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
There are only 2 projects using pypowervm (nova and nova-powervm)
and both are using min 1.1.15 so this changes the global min to
match.
Change-Id: Icc070ab9c34f3b086d0801bc7cc372390f601f3a
In the spirit of "python 3" first I would like to propose distro for
global-requirements.
The builtin platform.linux_distribution[1] is deprecated and will be
removed in 3.8 and the recommended replacement is distro. Since
linux_distribution is widely used in OpenStack projects[2], we should
have an approved alternative.
Is the library actively maintained?
Yes[3]
Is the library good code?
Yes, it is pretty simple code with 98% coverage[4]
Is the library license compatible?
Yes, Apache 2.0[5]
Is the library already packaged in the distros we target (Ubuntu latest
/ Fedora latest)?
Ubuntu since artful (17.10)
Fedora since 23
RHEL 6
Is the function of this library already covered by other libraries in
global-requirements.txt?
Not that I am aware of.
Is the library required for OpenStack project or related dev or
infrastructure setup? (Answer to this should be Yes, of course) Which?
As noted above[2], many OpenStack projects are using the deprecated
function. Octavia is one that would like to move to distro.
[1] https://docs.python.org/2/library/platform.html \
#platform.linux_distribution
[2] http://codesearch.openstack.org/?q=platform.linux_distribution
[3] https://pypi.org/project/distro/1.2.0/#history
[4] https://codecov.io/github/nir0s/distro?branch=master
[5] https://github.com/nir0s/distro/blob/master/LICENSE
Change-Id: Iee61fad7954a56b225221e5b5254ee8094911d43
Flask has move to 1.0 and is quite stable. New in 1.0+ is a lot
of beneficial test bits among other generally nice changes. In
moving Keystone to Flask, we would like to lean on the new test
capabilities in 1.0+
Change-Id: Ie0e8984c4c02a426eb1e7cbac8c5117aaaff5c40
fixtures-git uses faker to generate fake text for inserting in to files
when building test git repos for tools that wish to test with git.
Is the library actively maintained?
Yes - https://github.com/joke2k/faker
They appear to have made regular releases since 2016 averaging ~2 per
month.
Is the library good code?
Yes - Appears to be relatively straight forward to extend suggesting a
nice simple design and the documentation appears to cover most of the
different types of fake data in reasonable detail.
Is the library python 3 compatible?
Yes - though only for >=3.4
da96379c07/setup.py (L43)
Is the library license compatible?
Yes - MIT
Is the library already packaged in the distros we target (Ubuntu latest
/ Fedora latest)?
Fedora - Present since Fedora 27
Ubuntu - Present since 17.10
Is the function of this library already covered by other libraries in
global-requirements.txt?
I don't believe so, was unable to locate any other random text
generators.
Is the library required for OpenStack project or related dev or
infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes - fixtures-git uses it directly to generate text to be used for
testing by developer tools working with git repositories such as
git-upstream.
Change-Id: Ic1c0412fb1473465977af8244b3e61060296e7a1
Prior to 2.1.52 this package's namespace was rtslib, then became
rtslib_fb. This results in cinder having conditional imports
wherever this is used.
Newer versions have been out long enough now that we should be
safe upgrading. Since there were a few blacklisted releases, this
raises the minumum version past these known bad versions.
Change-Id: I5c3bd96ad5571d8c5a3a19d553bed03c9a1ec194
Due to the issue fixed in
I48a103e28d86128ea84466da4d9d6faab1dd9a9d, Alembic should be bumped
to version 0.9.6 going forward.
Change-Id: I1a8244edae47b04b7b1fed54e577d6534945bcd8
Closes-bug: #1776527
We would need to raise the min of tornado to 4.5 to be 'most' correct.
See https://github.com/jd/tenacity/issues/99 for details.
Change-Id: I5635c6a07c9a00b67e27aa4073314d12915b4d73
Version 2.1.3 contains important bugs that were fixed in version 2.1.5,
namely [1].
This is required for objects comparison in tests.
[1] 0af31e8637
Change-Id: I25d0fc64989074e85f44977a2d3215d098dd313a
networking-ansible ML2 driver invokes ansible via an ASL 2.0 python
wrapper named ansible-runner.
Is the library actively maintained?
Yes - https://github.com/ansible/ansible-runner
I've been working with the maintainers and they've been very responsive
Is the library good code?
Yes - Documentation has been good and contributing has been easy
stability has been good and good coding practices appear to be
practiced.
Is the library python 3 compatible?
Yes
b86c50978e
Is the library license compatible?
Yes - ASL 2.0
Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
Fedora - Yes
Ubuntu - No
Is the function of this library already covered by other libraries in global-requirements.txt?
I don't believe so. Afaik it's the only distibuted lib that provides a
programatic interface to ansible.
Is the library required for OpenStack project or related dev or infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes - networking-ansible invokes it directly to manage switching
infrastructure via Ansible Networking
Change-Id: I33725dbb61f0e6423ef358602822e2e6bcef4abd
The release 0.11.0 adds two new sets of commands for QoS and
Port_Group's that will be used by the networking-ovn project.
Change-Id: Ibde75d825ed9cdd56ca0388f97611df70775c15b
Version 2.5.0 contains NVMEoF commits that is needed by nova change:
https://review.openstack.org/#/c/482640/
Change-Id: I9a9f8b5c7de6197b05559e389a76ebce7099cf00
This library will be used in TripleO to manage Ironic deployments,
eventually replacing Nova in the undercloud. It was written by me
as a pool of shared code for using Ironic to avoid placing business
logic, useful outside of TripleO, inside TripleO code base.
Is the library actively maintained?
Yes (disclosure: I'm the developer)
Is the library good code?
Yes (passes our standard pep8 check, has 95% unit test coverage
and voting integration testing with devstack)
Is the library python 3 compatible?
Yes (voting unit tests job with python 3.5)
Is the library license compatible?
Yes (Apache 2.0)
Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
No (will work on RDO packaging soon)
Is the function of this library already covered by other libraries in global-requirements.txt?
No (only partial overlap with Nova and Mogan services)
Is the library required for OpenStack project or related dev or infrastructure setup?
Yes (TripleO blueprint nova-less-deploy)
Change-Id: If594db16db619eb9ab7f8e0b22cee065181121b9
spec-cleaner is used for rpm-packaging spec linting, it is not intended
as an OpenStack dependency per se. This could be added as a blacklisted
item as all the other linters are but rpm-packaging itself is not a
tracked project so it is not required to add it there.
Change-Id: I5c8c1926d7ce3f812ad80e5435f19ced601aae13
Projects that want to enable a comprehensive doc8 check of code,
including D000, need Pygmnets to be installable. It's an option library
used by docutils so we need to track it here.
While this isn't really a linter, neither is it really required at
runtime for the projects using it so it's added to the blacklist
Is the library actively maintained?
Yes - https://bitbucket.org/birkenfeld/pygments-main
Is the library good code?
Yes - It is the defacto syntax highlighting code in Python
Is the library python 3 compatible?
Yes
Is the library license compatible?
Yes - BSD
Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
Yes
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 - for doc8 checking where there is code snippets.
It is also a transient dependancy of sphinx - https://github.com/sphinx-doc/sphinx/blob/master/setup.py#L21
Change-Id: I643c7632a02c87820c9c51f03fa34f0764384783
Close-bug: #1771479
- Is the library actively maintained?
python-qinlingclient is actively maintained by qinling team.
- Is the library good code?
It has been developed following the OpenStack conventions and practices,
including pep8/hacking and unit testing.
- Is the library python 3 compatible?
Yes, we have py3 gate job running for the submitted patches.
- Is the library license compatible?
Yes, python-qinlingclient uses the Apache Software License
- Is the library already packaged in the distros we target (Ubuntu latest /
Fedora latest)?
No
- Is the function of this library already covered by other libraries in
global-requirements.txt?
No. python-qinlingclient is meant for interacting with Qinling service.
- Is the library required for OpenStack project or related dev or
infrastructure setup? (Answer to this should be Yes, of course) Which?
Yes. python-qinlingclient is meant for interacting with Qinling service.
- If the library release is managed by the Openstack release process does it
use the cycle-with-intermediary release type?
Yes
- Do I need to update anything else?
No
Change-Id: Ide609acb7493760cf373973f049035f7c97c7851
New xstatic projects are added and released on pypi site.
Add them to global requirements for referencing by other projects.
* Is the library actively maintained?
Yes. Maintained as xstatic projects.
* Is the library good code?
Yes. Published javascript code are adopted.
* Is the library python 3 compatible?
Yes.
* Is the library license compatible?
Yes. All provided with MIT License.
* Is the library already packaged in the distros we target
(Ubuntu latest / Fedora latest)?
Yes. Released on pypi site and can be simply installed with pip.
* Is the function of this library already covered
by other libraries in global-requirements.txt?
No. New functions are provided.
* Is the library required for OpenStack project
or related dev or infrastructure setup?
Yes. openstack/release changes are as follows.
xstatic-angular-uuid 558989
xstatic-angular-vis 559005
xstatic-filesaver 559007
xstatic-json2yaml 559017
xstatic-js-yaml 559028
* If the library release is managed by the Openstack release process
does it use the cycle-with-intermediary release type?
No. Managed by openstack/release as xstatic type.
* Do I need to update anything else?
I am not sure but think the answer is NO.
Changes to upper-constraints.txt and lower-constraints.txt
are already included in this commit.
Change-Id: I1112aea8a19c72abcbec8ea63b51c68f3486dcbc
Now it's published on PyPI.
Add it to global-requirements, following the similar change. [1]
This is necessary for networking-midonet. See [2].
Note: this is not a library. It provides a Neutron service plugin
as some of Neutron subprojects like neutron-vpnaas do.
networking-midonet has a driver for this service plugin and
associated unit tests, which currently requires this.
This commit doesn't add it to blacklist.txt because:
- as far as I know, networking-midonet is the only project which
uses tox_install to install tap-as-a-service
- and its gate is currently broken and we plan to retire
tox_install to fix it. [2]
[1] https://review.openstack.org/#/c/552865/
[2] https://review.openstack.org/#/c/555788/
The following answers the questions on:
https://docs.openstack.org/project-team-guide/dependency-management.html#for-new-requirements
> Is the library actively maintained?
It's maintained. Not very active these days though.
> Is the library good code?
It's following Neutron standard. (loosely)
> Is the library python 3 compatible?
Yes.
> Is the library license compatible?
Yes. Same license as Neutron.
> Is the library already packaged in the distros we target (Ubuntu latest / Fedora latest)?
https://packages.ubuntu.com/search?keywords=python-neutron-taas
I have no idea about Fedora.
> 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. networking-midonet has a driver for this project.
> If the library release is managed by the Openstack release process does it use the cycle-with-intermediary release type?
No. It isn't a library.
Ideally it should be cycle-with-milestones.
> Do I need to update anything else?
I'm not sure what this question means.
Change-Id: Ifed26d4cd9477b7d421718a95d475d85a9720e1f
Add opentracing and related libraries to OpenStack global requirements.
Notes:
- This work is in progress.
- On the way to make OpenStack OSprofiler compatible with CNCF OpenTracing.
Some questions:
>>> Is the library actively maintained?
Yes, a link for it: https://github.com/opentracing/opentracing-python
>>> Is the library good code?
Yes
>>> Is the library python 3 compatible?
Yes
>>> Is the library license compatible?
Yes, it is under Apache 2.0 license
>>> Is the library required for OpenStack project or related dev
>>> or infrastructure setup? Which?
Yes, this change: I8f75af487f50d5e67a1321a4c951d2a0d85733a1
>>> When will this land?
This patch is expected to land on Rocky
Related change: I8f75af487f50d5e67a1321a4c951d2a0d85733a1
Change-Id: Iaac3ac3853867a67f7e386e762e0522076235daf
This dependency is required for openstack/monasca-notification Jira
plugin. This is used for automatically creating issue in Jira issue
tracker.
* Is this library actively maintained?
Yes
* Is the library good code?
Yes
* Is the library python3 compatible?
Yes
* Is the library licence compatible?
Yes, BSD (2 clause)
* Is the library already packaged in the distros we target?
Ubuntu: Yes
Fedora: Yes
Debian: Yes
Gentoo: Yes
SUSE: Yes
* 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?
Required for monasca-notification JIRA plugin.
Change-Id: Id46f86607f54d945424e385ab00512ac01a6ecf5
This is required for running the skydive-client in a multithreaded code,
which is the case in Dragonflow.
Relevant patch: https://github.com/skydive-project/skydive/pull/933
Change-Id: Icc0f6800ad7f191562c2ea747fec18a122c8bb95
Because PyMI and WMI are not in the lower-requirements, the
requirements-check job fails in os-win [1]. This patch adds the
two requirements.
[1] Ia95aa8f003151cbce870acc54f2053cbcfc6effb
Change-Id: I9875ab24b1fda4e1492b173517ac4795c3f3276c
It will enable all osc plugins' shell interfaces make use of none
auth type.
Needed-By: https://review.openstack.org/359061
Change-Id: If371b942846582e853dfe34a1edf6c2258c4f74d
This packages up most of the functionality of the autodoc feature
currently found in pbr as a Sphinx extension and is necessary so we can
migrate everyone away from the 'setup.py build_sphinx' way of building
documentation.
Change-Id: If27c35e573b22f99ebe54b935bc583a91c3cd0d2
This is required as Dragonflow is now using this library for topology
visualization (https://review.openstack.org/#/c/518670/)
Library is maintatined at: https://github.com/skydive-project/skydive
Active IRC channel: #skydive-project
Compatibility: Python 2 / Python 3
License: Apache 2.0
After reviewing the code I believe it is a good one for OpenStack.
The library is available via pypi, but not yet via any distro packaging.
Other libraries (trollius 2.1 and asyncio 3.4.3 are required by skydive)
Change-Id: I89f37e9590de86ca8d6f6a48cf1673ea214b6d29
Newer release of os-brick contains support for extending
attached ScaleIO volumes as well as SMBFS mounting of
vhd/x images.
Change-Id: I3974d7732ae21cb12691f1056e0de3be985e15fe