2014-09-03 11:45:08 -05:00
|
|
|
# The order of packages is significant, because pip processes them in the order
|
|
|
|
# of appearance. Changing the order has an impact on the overall integration
|
|
|
|
# process, which may cause wedges in the gate later.
|
|
|
|
|
2017-04-13 16:27:09 +00:00
|
|
|
pbr!=2.1.0,>=2.0.0 # Apache-2.0
|
2019-09-02 12:44:50 +01:00
|
|
|
SQLAlchemy>=1.2.19 # MIT
|
2016-01-22 04:07:37 +00:00
|
|
|
decorator>=3.4.0 # BSD
|
Correct lower-constraints.txt and the related tox job
In the review of a similar change in placement [1], it was realized that
the nova lower-constraints tox job probably had the same problems.
Testing revealed this to be the case. This change fixes the job and
updates the related requirements problems accordingly.
The are two main factors at play here:
* The default install_command in tox.ini uses the upper_contraints.txt
file. When there is more than one constraints.txt they are merged and
the higher constraints win. Using upper and lower at the same time
violates the point of lower (which is to indicate the bare minimum
we are capable of using).
* When usedevelop is true in tox, the command that is run to install the
current projects code is something like 'python setup.py develop',
which installs a project's requirements _after_ the install_command has
run, clobbering the constrained installs. When using pbr,
'python setup.py install' (used when usedevelop is False) does not do
this.
Fixing those then makes it possible to use the test to fix the
lower-constraints.txt and *requirements.txt files, changes include:
* Defining 'usedevelop = False' in the 'lower-constraints' target and
removing the otherwise superfluous 'skipsdist' global setting to
ensure requirements aren't clobbered.
* Removing packages which show up in lower-constraints.txt but not in
the created virtualenv. Note that the job only runs unit tests, so
this may be incomplete. In the placement version of this both unit and
functional are run. We may want to consider that here.
* Updating cryptography. This version is needed with more recent
pyopenssl.
* Updated keystonemiddleware. This is needed for some tests which
confirm passing configuration to the middleware.
* Update psycopg2 to a version that can talk with postgresql 10.
* Add PyJWT, used by zVMCloudConnector
* Update zVMCloudConnector to a version that works with Python 3.5 and
beyond.
* Update olso.messaging to versions that work with the tests, under
Python 3.
* Adding missing transitive packages.
* Adjusting alpha-ordering to map to how pip freeze does it.
* setuptools is removed from requirements.txt because the created
virtualenv doesn't contain it
NOTE: The lower-constraints.txt file makes no commitment to expressing
minimum requirements for anything other than the current basepython.
So the fact that a different set of lower-constraints would be present
if we were using python2 is not relevant. See discussion at [1].
However, since requirements.txt _is_ used for python2, the
requirements-check gate job requires that enum34 be present in
lower-constraints.txt because it is in requirements.txt.
NOTE: A test is removed because it cannot work in the
lower-constraints context: 'test_policy_generator_from_command_line'
forks a call to 'oslopolicy-policy-generator --namespace nova' which
fails because stevedore fails to pick up nova-based entry points when
in a different process. This is because of the change to usedevelop.
After discussion with the original author of the test removal was
considered an acceptable choice.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2019-03-05.log.html#t2019-03-05T13:28:23
Closes-Bug: #1822575
Change-Id: Ic6466b0440a4fe012731a63715cf5d793b6ae4dd
2018-12-05 14:01:04 +00:00
|
|
|
eventlet!=0.20.1,>=0.20.0 # MIT
|
2018-03-06 12:57:20 +00:00
|
|
|
Jinja2>=2.10 # BSD License (3 clause)
|
Correct lower-constraints.txt and the related tox job
In the review of a similar change in placement [1], it was realized that
the nova lower-constraints tox job probably had the same problems.
Testing revealed this to be the case. This change fixes the job and
updates the related requirements problems accordingly.
The are two main factors at play here:
* The default install_command in tox.ini uses the upper_contraints.txt
file. When there is more than one constraints.txt they are merged and
the higher constraints win. Using upper and lower at the same time
violates the point of lower (which is to indicate the bare minimum
we are capable of using).
* When usedevelop is true in tox, the command that is run to install the
current projects code is something like 'python setup.py develop',
which installs a project's requirements _after_ the install_command has
run, clobbering the constrained installs. When using pbr,
'python setup.py install' (used when usedevelop is False) does not do
this.
Fixing those then makes it possible to use the test to fix the
lower-constraints.txt and *requirements.txt files, changes include:
* Defining 'usedevelop = False' in the 'lower-constraints' target and
removing the otherwise superfluous 'skipsdist' global setting to
ensure requirements aren't clobbered.
* Removing packages which show up in lower-constraints.txt but not in
the created virtualenv. Note that the job only runs unit tests, so
this may be incomplete. In the placement version of this both unit and
functional are run. We may want to consider that here.
* Updating cryptography. This version is needed with more recent
pyopenssl.
* Updated keystonemiddleware. This is needed for some tests which
confirm passing configuration to the middleware.
* Update psycopg2 to a version that can talk with postgresql 10.
* Add PyJWT, used by zVMCloudConnector
* Update zVMCloudConnector to a version that works with Python 3.5 and
beyond.
* Update olso.messaging to versions that work with the tests, under
Python 3.
* Adding missing transitive packages.
* Adjusting alpha-ordering to map to how pip freeze does it.
* setuptools is removed from requirements.txt because the created
virtualenv doesn't contain it
NOTE: The lower-constraints.txt file makes no commitment to expressing
minimum requirements for anything other than the current basepython.
So the fact that a different set of lower-constraints would be present
if we were using python2 is not relevant. See discussion at [1].
However, since requirements.txt _is_ used for python2, the
requirements-check gate job requires that enum34 be present in
lower-constraints.txt because it is in requirements.txt.
NOTE: A test is removed because it cannot work in the
lower-constraints context: 'test_policy_generator_from_command_line'
forks a call to 'oslopolicy-policy-generator --namespace nova' which
fails because stevedore fails to pick up nova-based entry points when
in a different process. This is because of the change to usedevelop.
After discussion with the original author of the test removal was
considered an acceptable choice.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2019-03-05.log.html#t2019-03-05T13:28:23
Closes-Bug: #1822575
Change-Id: Ic6466b0440a4fe012731a63715cf5d793b6ae4dd
2018-12-05 14:01:04 +00:00
|
|
|
keystonemiddleware>=4.20.0 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
lxml!=3.7.0,>=3.4.1 # BSD
|
2017-05-20 04:41:02 +00:00
|
|
|
Routes>=2.3.1 # MIT
|
2019-06-26 23:25:48 +00:00
|
|
|
cryptography>=2.7 # BSD/Apache-2.0
|
2018-06-29 11:44:23 +02:00
|
|
|
WebOb>=1.8.2 # MIT
|
2018-07-23 15:44:16 -04:00
|
|
|
# NOTE(mriedem): greenlet 0.4.14 does not work with older versions of gcc on
|
|
|
|
# ppc64le systems, see https://github.com/python-greenlet/greenlet/issues/136.
|
|
|
|
greenlet>=0.4.10,!=0.4.14 # MIT
|
2016-01-22 04:07:37 +00:00
|
|
|
PasteDeploy>=1.5.0 # MIT
|
2017-09-16 23:18:37 +00:00
|
|
|
Paste>=2.0.2 # MIT
|
2016-10-02 20:16:53 +00:00
|
|
|
PrettyTable<0.8,>=0.7.1 # BSD
|
2019-10-23 14:09:20 -04:00
|
|
|
sqlalchemy-migrate>=0.13.0 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
netaddr>=0.7.18 # BSD
|
2016-01-22 04:07:37 +00:00
|
|
|
netifaces>=0.10.4 # MIT
|
2017-08-18 15:53:20 +00:00
|
|
|
paramiko>=2.0.0 # LGPLv2.1+
|
2017-06-06 21:58:42 +00:00
|
|
|
Babel!=2.4.0,>=2.3.4 # BSD
|
2019-11-19 15:38:33 +01:00
|
|
|
enum34>=1.0.4;python_version=='2.7' or python_version=='2.6' or python_version=='3.3' # BSD
|
2016-04-30 18:07:08 +00:00
|
|
|
iso8601>=0.1.11 # MIT
|
2019-04-12 10:14:18 +10:00
|
|
|
jsonschema>=2.6.0 # MIT
|
2019-05-27 17:49:56 +08:00
|
|
|
python-cinderclient!=4.0.0,>=3.3.0 # Apache-2.0
|
2019-08-15 09:16:58 -05:00
|
|
|
keystoneauth1>=3.16.0 # Apache-2.0
|
2018-02-14 12:18:13 +00:00
|
|
|
python-neutronclient>=6.7.0 # Apache-2.0
|
2017-08-07 00:49:24 +00:00
|
|
|
python-glanceclient>=2.8.0 # Apache-2.0
|
2017-06-14 00:35:01 +00:00
|
|
|
requests>=2.14.2 # Apache-2.0
|
2017-11-16 11:16:21 +00:00
|
|
|
six>=1.10.0 # MIT
|
2017-03-02 11:50:48 +00:00
|
|
|
stevedore>=1.20.0 # Apache-2.0
|
2016-05-19 13:35:40 +00:00
|
|
|
websockify>=0.8.0 # LGPLv3
|
2017-10-11 05:50:00 +00:00
|
|
|
oslo.cache>=1.26.0 # Apache-2.0
|
2018-03-26 08:15:10 +00:00
|
|
|
oslo.concurrency>=3.26.0 # Apache-2.0
|
2018-06-28 16:10:03 +01:00
|
|
|
oslo.config>=6.1.0 # Apache-2.0
|
2019-08-01 13:43:30 +00:00
|
|
|
oslo.context>=2.21.0 # Apache-2.0
|
2018-01-16 12:40:17 +00:00
|
|
|
oslo.log>=3.36.0 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
oslo.reports>=1.18.0 # Apache-2.0
|
2018-10-22 12:37:37 -04:00
|
|
|
oslo.serialization!=2.19.1,>=2.21.1 # Apache-2.0
|
2018-09-18 21:28:22 +00:00
|
|
|
oslo.upgradecheck>=0.1.1
|
2019-09-04 06:47:48 -05:00
|
|
|
oslo.utils>=3.40.2 # Apache-2.0
|
2019-02-14 08:47:53 -05:00
|
|
|
oslo.db>=4.44.0 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
oslo.rootwrap>=5.8.0 # Apache-2.0
|
2019-09-20 19:07:19 +02:00
|
|
|
oslo.messaging>=10.3.0 # Apache-2.0
|
2019-08-01 13:43:30 +00:00
|
|
|
oslo.policy>=1.38.0 # Apache-2.0
|
2019-09-04 06:47:48 -05:00
|
|
|
oslo.privsep>=1.33.2 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
oslo.i18n>=3.15.3 # Apache-2.0
|
2019-09-04 06:47:48 -05:00
|
|
|
oslo.service>=1.40.1 # Apache-2.0
|
2018-12-26 09:43:48 +09:00
|
|
|
rfc3986>=1.1.0 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
oslo.middleware>=3.31.0 # Apache-2.0
|
2017-02-15 20:50:34 +00:00
|
|
|
psutil>=3.2.2 # BSD
|
2019-05-01 08:57:39 -04:00
|
|
|
oslo.versionedobjects>=1.35.0 # Apache-2.0
|
2018-10-30 11:51:03 +01:00
|
|
|
os-brick>=2.6.2 # Apache-2.0
|
Add extra spec parameter and image property for memory encryption
Add a new "hw:mem_encryption" extra spec parameter, and a new
"hw_mem_encryption" image property, which indicate that any guest
booted with that extra spec parameter or image property respectively
needs to be booted with its memory hardware-encrypted.
This is achieved by converting the requirement stated in the extra
spec parameter and/or image property into an additional extra spec
parameter which requests resources for one slot of the inventory of
the new MEM_ENCRYPTION_CONTEXT resource class (introduced in
os-resource-classes 0.4.0). The inventory will be provided by the
follow-up commit I659cb77f12a38a4d2fb118530ebb9de88d2ed30d.
Since future commits adding support for SEV to guest XML config will
also need to know at launch-time whether memory encryption has been
requested, add a reusable mem_encryption_requested() function to the
nova.virt.hardware library for detecting which of the extra spec /
image property (if either) have requested encrypted memory.
If both the extra spec parameter and the image property are explicitly
specified and they contradict each other, or if either request memory
encryption but the image does not have hw_firmware_type set to UEFI,
then log an error and raise a new generic FlavorImageConflict
exception. This exception can also be useful in the future for
handling other similar conflicts. In this particular use case,
FlavorImageConflict is raised by mem_encryption_requested(), and then
if caught during API call validation, it's re-raised as
HTTPBadRequest.
In order to test this code, we need to construct various ImageMeta
objects containing fake data and a ImageMetaProps instance for each.
This is a slightly fiddly task which future patches in the SEV series
will also need to perform, so add a helper to nova.tests.unit.image.fake
for this.
blueprint: amd-sev-libvirt-support
Change-Id: I8c63b5cc5ad97ce831adb2eb96a995ebc798ecb7
2019-06-10 18:15:40 +01:00
|
|
|
os-resource-classes>=0.4.0 # Apache-2.0
|
2019-10-16 11:57:34 -05:00
|
|
|
os-traits>=1.1.0 # Apache-2.0
|
2018-06-04 11:46:21 +02:00
|
|
|
os-vif>=1.14.0 # Apache-2.0
|
2018-01-29 00:21:52 +00:00
|
|
|
os-win>=3.0.0 # Apache-2.0
|
2017-12-19 01:53:09 +00:00
|
|
|
castellan>=0.16.0 # Apache-2.0
|
2018-03-23 22:44:04 +00:00
|
|
|
microversion-parse>=0.2.1 # Apache-2.0
|
2017-08-25 02:11:25 +00:00
|
|
|
os-xenapi>=0.3.3 # Apache-2.0
|
2017-09-13 12:57:19 +00:00
|
|
|
tooz>=1.58.0 # Apache-2.0
|
2018-01-09 02:22:53 +00:00
|
|
|
cursive>=0.2.1 # Apache-2.0
|
2018-04-25 11:34:22 -05:00
|
|
|
pypowervm>=1.1.15 # Apache-2.0
|
2018-06-15 23:10:32 +00:00
|
|
|
retrying>=1.3.3,!=1.3.0 # Apache-2.0
|
2019-04-11 15:12:19 -07:00
|
|
|
os-service-types>=1.7.0 # Apache-2.0
|
2018-01-15 15:08:25 -05:00
|
|
|
taskflow>=2.16.0 # Apache-2.0
|
2018-03-06 09:10:27 -08:00
|
|
|
python-dateutil>=2.5.3 # BSD
|
Correct lower-constraints.txt and the related tox job
In the review of a similar change in placement [1], it was realized that
the nova lower-constraints tox job probably had the same problems.
Testing revealed this to be the case. This change fixes the job and
updates the related requirements problems accordingly.
The are two main factors at play here:
* The default install_command in tox.ini uses the upper_contraints.txt
file. When there is more than one constraints.txt they are merged and
the higher constraints win. Using upper and lower at the same time
violates the point of lower (which is to indicate the bare minimum
we are capable of using).
* When usedevelop is true in tox, the command that is run to install the
current projects code is something like 'python setup.py develop',
which installs a project's requirements _after_ the install_command has
run, clobbering the constrained installs. When using pbr,
'python setup.py install' (used when usedevelop is False) does not do
this.
Fixing those then makes it possible to use the test to fix the
lower-constraints.txt and *requirements.txt files, changes include:
* Defining 'usedevelop = False' in the 'lower-constraints' target and
removing the otherwise superfluous 'skipsdist' global setting to
ensure requirements aren't clobbered.
* Removing packages which show up in lower-constraints.txt but not in
the created virtualenv. Note that the job only runs unit tests, so
this may be incomplete. In the placement version of this both unit and
functional are run. We may want to consider that here.
* Updating cryptography. This version is needed with more recent
pyopenssl.
* Updated keystonemiddleware. This is needed for some tests which
confirm passing configuration to the middleware.
* Update psycopg2 to a version that can talk with postgresql 10.
* Add PyJWT, used by zVMCloudConnector
* Update zVMCloudConnector to a version that works with Python 3.5 and
beyond.
* Update olso.messaging to versions that work with the tests, under
Python 3.
* Adding missing transitive packages.
* Adjusting alpha-ordering to map to how pip freeze does it.
* setuptools is removed from requirements.txt because the created
virtualenv doesn't contain it
NOTE: The lower-constraints.txt file makes no commitment to expressing
minimum requirements for anything other than the current basepython.
So the fact that a different set of lower-constraints would be present
if we were using python2 is not relevant. See discussion at [1].
However, since requirements.txt _is_ used for python2, the
requirements-check gate job requires that enum34 be present in
lower-constraints.txt because it is in requirements.txt.
NOTE: A test is removed because it cannot work in the
lower-constraints context: 'test_policy_generator_from_command_line'
forks a call to 'oslopolicy-policy-generator --namespace nova' which
fails because stevedore fails to pick up nova-based entry points when
in a different process. This is because of the change to usedevelop.
After discussion with the original author of the test removal was
considered an acceptable choice.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-dev/%23openstack-dev.2019-03-05.log.html#t2019-03-05T13:28:23
Closes-Bug: #1822575
Change-Id: Ic6466b0440a4fe012731a63715cf5d793b6ae4dd
2018-12-05 14:01:04 +00:00
|
|
|
zVMCloudConnector>=1.3.0;sys_platform!='win32' # Apache 2.0 License
|
2018-12-12 16:13:55 +01:00
|
|
|
futurist>=1.8.0 # Apache-2.0
|
2019-08-16 07:48:50 -05:00
|
|
|
openstacksdk>=0.35.0 # Apache-2.0
|