nova/requirements.txt

75 lines
2.5 KiB
Plaintext
Raw Normal View History

# 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.
pbr!=2.1.0,>=2.0.0 # Apache-2.0
SQLAlchemy>=1.2.19 # MIT
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
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
lxml!=3.7.0,>=3.4.1 # BSD
Routes>=2.3.1 # MIT
cryptography>=2.7 # BSD/Apache-2.0
WebOb>=1.8.2 # MIT
# 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
PasteDeploy>=1.5.0 # MIT
Paste>=2.0.2 # MIT
PrettyTable<0.8,>=0.7.1 # BSD
sqlalchemy-migrate>=0.13.0 # Apache-2.0
netaddr>=0.7.18 # BSD
netifaces>=0.10.4 # MIT
paramiko>=2.0.0 # LGPLv2.1+
Babel!=2.4.0,>=2.3.4 # BSD
enum34>=1.0.4;python_version=='2.7' or python_version=='2.6' or python_version=='3.3' # BSD
iso8601>=0.1.11 # MIT
jsonschema>=2.6.0 # MIT
python-cinderclient!=4.0.0,>=3.3.0 # Apache-2.0
keystoneauth1>=3.16.0 # Apache-2.0
python-neutronclient>=6.7.0 # Apache-2.0
python-glanceclient>=2.8.0 # Apache-2.0
requests>=2.14.2 # Apache-2.0
six>=1.10.0 # MIT
stevedore>=1.20.0 # Apache-2.0
websockify>=0.8.0 # LGPLv3
oslo.cache>=1.26.0 # Apache-2.0
oslo.concurrency>=3.26.0 # Apache-2.0
oslo.config>=6.1.0 # Apache-2.0
oslo.context>=2.21.0 # Apache-2.0
oslo.log>=3.36.0 # Apache-2.0
oslo.reports>=1.18.0 # Apache-2.0
Fix jsonutils.to_primitive UserWarning The CheatingSerializer fixture used in nova tests keeps the RequestContext.db_connection set on the context object which otherwise wouldn't normally happen. The context object can show up in error notification payloads because of how nova.exception_wrapper.wrap_exception works. That payload is eventually serialized for notifications and since the cheated RequestContext.db_connection is set and cannot be serialized, it results in a UserWarning from the jsonutils.to_primitive method (called via JsonPayloadSerializer). This will eventually result in failures when that UserWarning is made into an error. To fix this, we can pass a fallback method to to_primitive() which will serialize a RequestContext object the same way that RequestContextSerializer serializes a context - by simply converting it to dict form. Since this only affects test runs, because of using the CheatingSerializer fixture, it should have no impact on runtime serializations. Error logging is added to the FakeNotifier since it's hard to know what is wrong in the payload unless it is logged. Also, the WarningsFixture is updated to make sure we don't introduce new UserWarnings for the serialization issue. The jsonutils.to_primitive() fallback method was added to oslo.serialization via commit cdb2f60d26e3b65b6370f87b2e9864045651c117 in 2.21.1 so we have to bump our minimum required version of that library as well. Change-Id: Id9f960a0c7c8897dbb9edf53b4723154341412d6 Closes-Bug: #1799249
2018-10-22 12:37:37 -04:00
oslo.serialization!=2.19.1,>=2.21.1 # Apache-2.0
oslo.upgradecheck>=0.1.1
oslo.utils>=3.40.2 # Apache-2.0
oslo.db>=4.44.0 # Apache-2.0
oslo.rootwrap>=5.8.0 # Apache-2.0
oslo.messaging>=10.3.0 # Apache-2.0
oslo.policy>=1.38.0 # Apache-2.0
oslo.privsep>=1.33.2 # Apache-2.0
oslo.i18n>=3.15.3 # Apache-2.0
oslo.service>=1.40.1 # Apache-2.0
rfc3986>=1.1.0 # Apache-2.0
oslo.middleware>=3.31.0 # Apache-2.0
psutil>=3.2.2 # BSD
oslo.versionedobjects>=1.35.0 # Apache-2.0
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
os-traits>=1.1.0 # Apache-2.0
os-vif>=1.14.0 # Apache-2.0
os-win>=3.0.0 # Apache-2.0
castellan>=0.16.0 # Apache-2.0
microversion-parse>=0.2.1 # Apache-2.0
os-xenapi>=0.3.3 # Apache-2.0
tooz>=1.58.0 # Apache-2.0
cursive>=0.2.1 # Apache-2.0
pypowervm>=1.1.15 # Apache-2.0
retrying>=1.3.3,!=1.3.0 # Apache-2.0
os-service-types>=1.7.0 # Apache-2.0
taskflow>=2.16.0 # Apache-2.0
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
futurist>=1.8.0 # Apache-2.0
openstacksdk>=0.35.0 # Apache-2.0