openstack/cinder
Code Issues Proposed changes
55b7aa9142
cinder/setup.cfg

143 lines
4.8 KiB
INI
Raw Normal View History

Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
[metadata]
name = cinder
Update metadata in setup.cfg we are using some "aliases" that the setuptools docs say "are supported for compatibility reasons" but their use is not advised[1]. [1] https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#metadata maintaining setup.cfg as per other repos[2] [2] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/828475 Change-Id: I08f81179f4c1229aae990f4f1487831f9a9a2921
2022-08-29 16:49:21 +05:30
description = OpenStack Block Storage
long_description = file: README.rst
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
author = OpenStack
setup.cfg: Replace dashes with underscores Resolves warnings like the following: UserWarning: Usage of dash-separated 'description-file' will not be supported in future versions. Please use the underscore name 'description_file' instead Change-Id: Ie12ecf09c30b1b53228882ba252813cd87dfa251 Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2021-04-20 16:40:01 +01:00
author_email = openstack-discuss@lists.openstack.org
Update metadata in setup.cfg we are using some "aliases" that the setuptools docs say "are supported for compatibility reasons" but their use is not advised[1]. [1] https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#metadata maintaining setup.cfg as per other repos[2] [2] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/828475 Change-Id: I08f81179f4c1229aae990f4f1487831f9a9a2921
2022-08-29 16:49:21 +05:30
url = https://docs.openstack.org/cinder/latest/
Drop python3.6 support in testing runtime In Zed cycle testing runtime, we are targetting to drop the python 3.6 support, project started adding python 3.8 as minimum, example nova: - https://github.com/openstack/nova/blob/56b5aed08c6a3ed81b78dc216f0165ebfe3c3350/setup.cfg#L13 Change-Id: I1e0d0a43cd166e6cfd4be7ca0f426e9fc3625a28
2022-04-27 14:13:11 +08:00
python_requires = >=3.8
Update metadata in setup.cfg we are using some "aliases" that the setuptools docs say "are supported for compatibility reasons" but their use is not advised[1]. [1] https://setuptools.pypa.io/en/latest/userguide/declarative_config.html#metadata maintaining setup.cfg as per other repos[2] [2] https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/828475 Change-Id: I08f81179f4c1229aae990f4f1487831f9a9a2921
2022-08-29 16:49:21 +05:30
classifiers =
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
Environment :: OpenStack
Intended Audience :: Information Technology
Intended Audience :: System Administrators
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
Programming Language :: Python
Cleanup py27 support This repo is now testing only with Python 3, so let's 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 obsolete sections from setup.cfg - Update classifiers - Use newer openstackdocstheme, Sphinx, os-api-ref versions, remove unused mock requirement Change-Id: If7db350ea55a5edf7055ce049d27d9412b0e40bc
2020-04-17 10:50:32 +02:00
Programming Language :: Python :: Implementation :: CPython
Programming Language :: Python :: 3 :: Only
Add python 3.5 in classifier Now we can support py35 in classifier. Change-Id: Ief555aa3211b0c1405d2abb155f9ddd44fa149fc
2017-06-27 15:54:48 +05:30
Programming Language :: Python :: 3
Switch to py38 and update version metadata As part of Victoria, the highest python version to support is now Python 3.8. See [0] for full details of the expected runtimes to support. This switches over functional testing to use 3.8 and updates the projects metadata to declare 3.8 as a supported runtime. [0] https://governance.openstack.org/tc/reference/runtimes/victoria.html Change-Id: Ica2dade49a65e749acc701bc16127809a7f079d6 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-04-15 12:41:58 -05:00
Programming Language :: Python :: 3.8
Updating python testing as per Yoga testing runtime Yoga testing runtime[1] has been updated to add py39 testing as voting and as we are testing py3.6 and py3.9 we do not need to test py3.7|8 explicitly. Unit tests update are handled by the job template change in openstack-zuul-job - https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/820286 this commit makes other required changes in zuul.yaml and update the classifier in setup.cfg file. [1] https://governance.openstack.org/tc/reference/runtimes/yoga.html Change-Id: I9fe6187ea8c849812a508b48b342226e50fca831
2021-11-24 17:23:06 -06:00
Programming Language :: Python :: 3.9
Add Python 3.10 to setup.cfg metadata We support 3.10 as of Antelope. Change-Id: Ie2a78085b62ce2f1fb55968057c20fef5b87653b
2023-03-09 11:24:33 -05:00
Programming Language :: Python :: 3.10
Update python classifier in setup.cfg As per the current release tested runtime, we test till python 3.11 so updating the same in python classifier in setup.cfg Change-Id: I704213dde1d9292034e2a87162b3a6382396cc1f
2024-01-08 20:18:56 -08:00
Programming Language :: Python :: 3.11
Add links to package metadata This adds the Source and Tracker links to our package metadata so that the links show up on the PyPi page for this package. https://pypi.org/project/cinder/ Change-Id: I704b3c41611c4778443256a0533e0522056985a4 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-06-23 07:14:28 -05:00
project_urls:
Source=https://opendev.org/openstack/cinder
Tracker=https://bugs.launchpad.net/cinder
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
[files]
Add default configuration files to data_files In order to make it simpler to use the default configuration files when deploying services from source, the files are added to pbr's data_files section so that the files are included in the built wheels and therefore deployed with the code. Packaging and deployment tools can then more easily use the default files if they wish to. This pattern is already established with similar files for neutron and the glance metadefs as has been mentioned in the related bug report. Change-Id: Idbc616e9ca23b1b7187f39a1e157f56862851f6c Closes-Bug: #1718356
2017-09-21 14:02:21 +01:00
data_files =
etc/cinder =
etc/cinder/api-paste.ini
etc/cinder/rootwrap.conf
add resource filters to the included data_files The resource_filters.json file has been added to the included data files which will allow packagers to rely on the default file instead of having to carry it as a template. Change-Id: I2a0120c4ab199ef7ede09a707de8540ce98809af Signed-off-by: Kevin Carter <kevin@cloudnull.com>
2019-01-08 11:37:24 -06:00
etc/cinder/resource_filters.json
Add default configuration files to data_files In order to make it simpler to use the default configuration files when deploying services from source, the files are added to pbr's data_files section so that the files are included in the built wheels and therefore deployed with the code. Packaging and deployment tools can then more easily use the default files if they wish to. This pattern is already established with similar files for neutron and the glance metadefs as has been mentioned in the related bug report. Change-Id: Idbc616e9ca23b1b7187f39a1e157f56862851f6c Closes-Bug: #1718356
2017-09-21 14:02:21 +01:00
etc/cinder/rootwrap.d = etc/cinder/rootwrap.d/*
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
packages =
cinder
[entry_points]
cinder.scheduler.filters =
Move oslo-incubator's scheduler module to cinder oslo-incubator is ending its life and we should move remaining dependencies from there to cinder namespace. This commit does so with openstack.common.scheduler. Apart from that tests from oslo-incubator repository are added. Change-Id: I10d88c120c9c847826986483065f5493e91f89d6 Closes-Bug: 1519337
2015-11-24 15:42:17 +01:00
AvailabilityZoneFilter = cinder.scheduler.filters.availability_zone_filter:AvailabilityZoneFilter
CapabilitiesFilter = cinder.scheduler.filters.capabilities_filter:CapabilitiesFilter
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
CapacityFilter = cinder.scheduler.filters.capacity_filter:CapacityFilter
Add affinity/anti-affinity filters Cinder has done a good job hiding the details of storage backends from end users by using volume types. However there are use cases where users who build their application on top of volumes would like to be able to 'choose' where a volume be created on. How can Cinder provide such capability without hurting the simplicity we have been keeping? Affinity/anti-affinity is one of the flexibility we can provide without exposing details to backends. The term affinity/anti-affinity here is to to describe the relationship between two sets of volumes in terms of location. To limit the scope, we describe one volume is affinity with the other one only when they reside in the same volume back-end (this notion can be extended to volume pools if volume pool support lands in Cinder); on the contrary, 'anti-affinity' relation between two sets of volumes simply implies they are on different Cinder back-ends (pools). This affinity/anti-affinity filter filters Cinder backend based on hint specified by end user. The hint expresses the affinity or anti-affinity relation between new volumes and existing volume(s). This allows end users to provide hints like 'please put this volume to a place that is different from where Volume-XYZ resides in'. This change adds two new filters to Cinder - SameBackendFilter and DifferentBackendFilter. These two filters will look at the scheduler hint provided by end users (via scheduler hint extension) and filter backends by checking the 'host' of old and new volumes see if a backend meets the requirement (being on the same backend as existing volume or not being on the same backend(s) as existing volume(s)). For example: Volume A is on 'backend 1', to create Volume B on the same backend as A, use: cinder create --hint same_host=VolA-UUID SIZE To create Volume C on different backend than that of A, use: cinder create --hint different_host=VolA-UUID SIZE Now, to create Volume D on different backend other than those of A and C, use: cinder create --hint different_host=VolA-UUID --hint different_host=VolC-UUID SIZE or: cinder create --hint different_host="[VolA-UUID, VolC-UUID]" SIZE implements bp: affinity-antiaffinity-filter DocImpact Change-Id: I19f298bd87b0069c0d1bb133202188d3bf65b770
2014-01-28 14:23:04 +08:00
DifferentBackendFilter = cinder.scheduler.filters.affinity_filter:DifferentBackendFilter
Add driver filter and evaluator for scheduler This patch adds a new filter for the cinder scheduler that can interpret two new properties provided by backends, 'filter_function' and 'goodness_function'. A driver can rely on cinder.conf entries to define these properties for a backend or the driver can generate them some other way. An evaluator is used by the filter to parse the properties. The 'goodness_function' property is used to weigh qualified backends in case multiple ones pass the filter. More details can be found in the spec: https://review.openstack.org/#/c/129330/ Implements: blueprint filtering-weighing-with-driver-supplied-functions DocImpact: New optional backend properties in cinder.conf. New filter and weigher available for scheduler. Change-Id: I38408ab49b6ed869c1faae746ee64a3bae86be58
2014-12-08 06:52:18 -08:00
DriverFilter = cinder.scheduler.filters.driver_filter:DriverFilter
Move oslo-incubator's scheduler module to cinder oslo-incubator is ending its life and we should move remaining dependencies from there to cinder namespace. This commit does so with openstack.common.scheduler. Apart from that tests from oslo-incubator repository are added. Change-Id: I10d88c120c9c847826986483065f5493e91f89d6 Closes-Bug: 1519337
2015-11-24 15:42:17 +01:00
JsonFilter = cinder.scheduler.filters.json_filter:JsonFilter
RetryFilter = cinder.scheduler.filters.ignore_attempted_hosts_filter:IgnoreAttemptedHostsFilter
Add affinity/anti-affinity filters Cinder has done a good job hiding the details of storage backends from end users by using volume types. However there are use cases where users who build their application on top of volumes would like to be able to 'choose' where a volume be created on. How can Cinder provide such capability without hurting the simplicity we have been keeping? Affinity/anti-affinity is one of the flexibility we can provide without exposing details to backends. The term affinity/anti-affinity here is to to describe the relationship between two sets of volumes in terms of location. To limit the scope, we describe one volume is affinity with the other one only when they reside in the same volume back-end (this notion can be extended to volume pools if volume pool support lands in Cinder); on the contrary, 'anti-affinity' relation between two sets of volumes simply implies they are on different Cinder back-ends (pools). This affinity/anti-affinity filter filters Cinder backend based on hint specified by end user. The hint expresses the affinity or anti-affinity relation between new volumes and existing volume(s). This allows end users to provide hints like 'please put this volume to a place that is different from where Volume-XYZ resides in'. This change adds two new filters to Cinder - SameBackendFilter and DifferentBackendFilter. These two filters will look at the scheduler hint provided by end users (via scheduler hint extension) and filter backends by checking the 'host' of old and new volumes see if a backend meets the requirement (being on the same backend as existing volume or not being on the same backend(s) as existing volume(s)). For example: Volume A is on 'backend 1', to create Volume B on the same backend as A, use: cinder create --hint same_host=VolA-UUID SIZE To create Volume C on different backend than that of A, use: cinder create --hint different_host=VolA-UUID SIZE Now, to create Volume D on different backend other than those of A and C, use: cinder create --hint different_host=VolA-UUID --hint different_host=VolC-UUID SIZE or: cinder create --hint different_host="[VolA-UUID, VolC-UUID]" SIZE implements bp: affinity-antiaffinity-filter DocImpact Change-Id: I19f298bd87b0069c0d1bb133202188d3bf65b770
2014-01-28 14:23:04 +08:00
SameBackendFilter = cinder.scheduler.filters.affinity_filter:SameBackendFilter
Add an instance-locality filter Having an instance and an attached volume on the same physical host (i.e. data locality) can be desirable in some configurations, in order to achieve high-performance disk I/O. This patch adds an InstanceLocalityFilter filter that allow users to request creation of volumes 'local' to an existing instance, without specifying the hypervisor's hostname, and without any knowledge of the underlying back-ends. In order to work: - At least one physical host should run both nova-compute and cinder-volume services. - The Extended Server Attributes extension needs to be active in Nova (this is by default), so that the 'OS-EXT-SRV-ATTR:host' property is returned when requesting instance info. - The user making the call needs to have sufficient rights for the property to be returned by Nova. This can be achieved either by changing Nova's policy.json (the 'extended_server_attributes' option), or by setting an account with privileged rights in Cinder conf. For example: Instance 01234567-89ab-cdef is running in a hypervisor on the physical host 'my-host'. To create a 42 GB volume in a back-end hosted by 'my-host': cinder create --hint local_to_instance=01234567-89ab-cdef 42 Note: Currently it is not recommended to allow instance migrations for hypervisors where this hint will be used. In case of instance migration, a previously locally-created volume will not be automatically migrated. Also in case of instance migration during the volume's scheduling, the result is unpredictable. DocImpact: New Cinder scheduler filter Change-Id: Id428fa2132c1afed424443083645787ee3cb0399
2014-12-05 16:09:10 +01:00
InstanceLocalityFilter = cinder.scheduler.filters.instance_locality_filter:InstanceLocalityFilter
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
cinder.scheduler.weights =
Add AllocatedCapacityWeigher AllocatedCapacityWeigher is a weigher that weigh hosts by their allocated capacity. The main purpose of this weigher is to simulate the SimpleScheduler's behavior, which sorts hosts by the size of all volumes on them. So by allocated capacity, it equals to the sum of size of all volumes on target host. In order to keep track of 'allocated' capacity, host state is updated to add a 'allocated_capacity_gb' attribute to record the value, which means each back-end must report one extra stats to scheduler. Fortunately, the 'allocated' capacity we are interested in here is pure Cinder level capacity, the volume manager can take all the burden to calculate this value without having to query back-ends. The volume manager does the initial calculation in init_host() by the time when it has to query all existing volumes from DB for ensure_export(). After initial calculation, volume manager/scheduler will keep track of every new request that changes 'allocated_capacity' and make sure this value is up to date. !DriverImpact! Cinder driver developers, please read on: This patch contains a change that might IMPACT volume drivers: volume manager now uses 'stats' attribute to save 'allocated_capacity_gb'. And this information will be merged with those stats drivers provide as a whole for scheduler to consume. If you plan to report any form of allocated space other than the apparent Cinder level value, (e.g. actual capacity allocated), Please choose a key name other than 'allocated_capacity_gb', otherwise it will *OVERWRITE* the value volume manager has calculated and confuse scheduler. Partially implements bp: deprecate-chance-and-simple-schedulers Change-Id: I306230b8973c2d1ad77bcab14ccde68e997ea816
2013-12-11 21:46:38 +08:00
AllocatedCapacityWeigher = cinder.scheduler.weights.capacity:AllocatedCapacityWeigher
Use pbr instead of openstack.common.setup. Fixes bug 1179007 Change-Id: I71a556bcc36e56f0b51b1191f2622c66c3338474
2013-04-20 21:35:37 -07:00
CapacityWeigher = cinder.scheduler.weights.capacity:CapacityWeigher
Add chance weigher to scheduler Adds chance weigher to scheduler to allow distribution of requests randomly between a number of volume managers. Change-Id: I3f652caf200c406965b52b94cebb244d3bc1779a
2013-11-27 10:26:03 +00:00
ChanceWeigher = cinder.scheduler.weights.chance:ChanceWeigher
Add driver filter and evaluator for scheduler This patch adds a new filter for the cinder scheduler that can interpret two new properties provided by backends, 'filter_function' and 'goodness_function'. A driver can rely on cinder.conf entries to define these properties for a backend or the driver can generate them some other way. An evaluator is used by the filter to parse the properties. The 'goodness_function' property is used to weigh qualified backends in case multiple ones pass the filter. More details can be found in the spec: https://review.openstack.org/#/c/129330/ Implements: blueprint filtering-weighing-with-driver-supplied-functions DocImpact: New optional backend properties in cinder.conf. New filter and weigher available for scheduler. Change-Id: I38408ab49b6ed869c1faae746ee64a3bae86be58
2014-12-08 06:52:18 -08:00
GoodnessWeigher = cinder.scheduler.weights.goodness:GoodnessWeigher
Support Volume Num Weighter Currently cinder support choosing volume backend according to free_capacity and allocated_capacity. Volume Num Weighter is that scheduler could choose volume backend based on volume number in volume backend, which could provide another mean to help improve volume-backends' IO balance and volumes' IO performance, see details in ref [1] and [2]. blueprint support-volume-num-weighter Ref: [1]https://blueprints.launchpad.net/cinder/+spec/support-volume-num-weighter [2]https://review.openstack.org/#/c/99683/ Change-Id: Id9275ed954f1b35ee8d7bee0f0b61cc3a7c48f63
2014-06-25 10:40:38 +08:00
VolumeNumberWeigher = cinder.scheduler.weights.volume_number:VolumeNumberWeigher
Dynamically create cinder.conf.sample As it stands, the opts.py file that is passed into oslo-config-generator isn't being generated dynamically and the old way of generating the cinder.conf.sample is dependent on oslo-incubator which Cinder is trying to move away from. oslo-config-generator works differently than oslo-incubator so a number of changes had to be made in order to make this switch. This patch adds the config directory to Cinder and in it are two files: -generate_cinder_opts.py that will take the results of a grep command to create the opts.py file to be passed into oslo-config-generator. -cinder.conf which is the new configuration for oslo-config-generator. The file is inside the config directory to be consistent with other projects. Some changes were made to the generate_sample.sh file in order to give the base directories and target directories to the generate_cinder_opts.py program. tox.ini was edited to remove the checkonly option because all that needs to happen in check_uptodate.sh is a check to ensure that the cinder.conf.sample is actually being generated with no issues. All options were removed from the check_uptodate.sh because they were unnecessary given the new, more simple way of generating the cinder.conf.sample. setup.cfg was also edited in order to add information oslo-config-generator needs to run. Co-Authored By: Jay Bryant <jsbryant@us.ibm.com> Co-Authored By: Jacob Gregor <jgregor@us.ibm.com> Change-Id: I643dbe5675ae9280e204f691781e617266f570d5 Closes-Bug: 1473768 Closes-Bug: 1437904 Closes-Bug: 1381563
2015-08-13 10:17:36 -05:00
oslo.config.opts =
cinder = cinder.opts:list_opts
Moved CORS middleware configuration into oslo-config-generator The default values needed for cinder's implementation of cors middleware have been moved from paste.ini into the configuration hooks provided by oslo.config. Furthermore, these values have been added to cinder's default configuration parsing. This ensures that if a value remains unset in cinder.conf, it will be set to use sane defaults, and that an operator modifying the configuration file will be presented with a default set of necessary sane headers. Depends-on: I658e54966c390b41e3b551dd9827606c2e013511 Change-Id: Ia8735d5952d7e03b6948f748afead13e6f890271 Closes-Bug: 1551836
2016-03-01 11:31:40 -08:00
oslo.config.opts.defaults =
Correct default policy_file in the sample config When the sample config is generated, the policy_file default value specified by oslo.policy is showing up, not the default value that Cinder is using. Correct this by enhancing the function specified for cinder in the oslo.config.opts.defaults entry point. This patch exposed Bug #1807184 in oslo.policy. The requirements and lower-constraints changes on this patch bump the minimum version of oslo.policy we use to include the fix (1.44.1). This version was already included in upper-constraints by Change I50bb9d48106376f5baaafae372492c0744182da2. Change-Id: Ic28d660a9d876139f47f98cf1024a30b005cd0e0 Closes-bug: #1807071
2018-12-05 22:12:13 -05:00
cinder = cinder.common.config:set_external_library_defaults
[policy in code] Add support for attachment resource This is the basic patch which consits of the framework code for default policy in code feature as well as support in attachment resource. Change-Id: Ie3ff068e61ea8e0e8fff78deb732e183e036a10c Partial-Implements: blueprint policy-in-code
2017-09-23 11:05:31 +08:00
oslo.policy.enforcer =
cinder = cinder.policy:get_enforcer
oslo.policy.policies =
# The sample policies will be ordered by entry point and then by list
# returned from that entry point. If more control is desired split out each
# list_rules method into a separate entry point rather than using the
# aggregate method.
cinder = cinder.policies:list_rules
Use oslo.rootwrap library instead of local copy Remove rootwrap code copied from oslo-incubator, make cinder-rootwrap a console_script entrypoint pointing in oslo.rootwrap instead. Change-Id: I4e924bc9fccd7f5a8522ac38b7c6d29683990ea8 Implements: blueprint cinder-oslo-rootwrap
2014-01-17 11:28:17 +01:00
console_scripts =
Use pbr entry_points to setup the cinder scripts The following patch changes how cinder scripts are installed and unit tested. This patch moves all the cinder scripts from bin into cinder/cmd and creates entry_points for those scripts in setup.cfg. When cinder is installed, these scripts will be installed under /usr/local/bin by pbr. DocImpact: 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis Change-Id: If82cf0c58d765bf79dbf721ca95c10a468940cab Implements: blueprint unit-test-cases-for-cinder-scripts
2014-06-20 00:30:36 -04:00
cinder-api = cinder.cmd.api:main
cinder-backup = cinder.cmd.backup:main
cinder-manage = cinder.cmd.manage:main
Change oslo.* to oslo_* Change oslo.db to oslo_db Change oslo.config to olso_config Change oslo.rootwrap to oslo_rootwrap The oslo libraries are moving away from namespace packages. Partial-bug: 1409733 Change-Id: I3429282afa2db4c0b3aa630eb3a0eaece04405ed
2015-02-03 13:19:40 -08:00
cinder-rootwrap = oslo_rootwrap.cmd:main
Use pbr entry_points to setup the cinder scripts The following patch changes how cinder scripts are installed and unit tested. This patch moves all the cinder scripts from bin into cinder/cmd and creates entry_points for those scripts in setup.cfg. When cinder is installed, these scripts will be installed under /usr/local/bin by pbr. DocImpact: 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis Change-Id: If82cf0c58d765bf79dbf721ca95c10a468940cab Implements: blueprint unit-test-cases-for-cinder-scripts
2014-06-20 00:30:36 -04:00
cinder-rtstool = cinder.cmd.rtstool:main
cinder-scheduler = cinder.cmd.scheduler:main
Base framework for cinder-status upgrade check This adds the cinder-status CLI for performing upgrade checks as part of the Stein cycle upgrade-checkers goal. It only includes a placeholder for actual checks. Follow up patches will need to be added for anything we identify as needing specific checking. Story: 2003657 Task: 26123 Change-Id: I2e532d313d12e60848b17e869882e52ec456929b Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2018-09-21 14:37:48 -05:00
cinder-status = cinder.cmd.status:main
Use pbr entry_points to setup the cinder scripts The following patch changes how cinder scripts are installed and unit tested. This patch moves all the cinder scripts from bin into cinder/cmd and creates entry_points for those scripts in setup.cfg. When cinder is installed, these scripts will be installed under /usr/local/bin by pbr. DocImpact: 'host' config option for multiple-storage backends in cinder.conf is renamed to 'backend_host' in order to avoid a naming conflict with the 'host' to locate redis Change-Id: If82cf0c58d765bf79dbf721ca95c10a468940cab Implements: blueprint unit-test-cases-for-cinder-scripts
2014-06-20 00:30:36 -04:00
cinder-volume = cinder.cmd.volume:main
cinder-volume-usage-audit = cinder.cmd.volume_usage_audit:main
Use pbr wsgi_scripts to install Cinder WSGI entry point pbr 1.4.0 added support for wsgi_scripts that creates scripts for wsgi servers on install. Change-Id: Ifbab059001d1567b1f7b394c0411a9ca4629f846 Closes-Bug: #1500367
2015-09-28 15:35:58 +03:00
wsgi_scripts =
cinder-wsgi = cinder.wsgi.wsgi:initialize_application
DB migration tests Refactored migration tests to use OpportunisticTestCase, removed unused code and ``test_migrations.conf`` file. The main feature of this approach is to create a new database with random name for each migration test. This will avoid migration tests of race conditions and reduce tests intersection. After this change, database ``openstack_citest`` will be used only for initial connection to the database. ``test_migrations.conf`` file not required anymore, because we create test database for migration test, so we no longer need to keep database credentials. Implements blueprint: db-migration-tests Related-bug: #1266595 Change-Id: I4febd485ff53936b636947c86773a23724e24c65
2014-10-29 15:52:54 +02:00
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
[extras]
all =
Reintroduce DataCore driver Related-Blueprint: datacore-volume-cinder-driver Change-Id: I69228275fc36fb96c40fd219a9fb2f5d5e5b3cde
2022-04-07 21:49:49 +05:30
websocket-client>=1.3.2 # LGPLv2+
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
pyOpenSSL>=17.5.0 # Apache-2.0
storops>=0.5.10 # Apache-2.0
pywbem>=0.7.0 #LGPLv2.1+
setup.cfg: [extras] for pip-installable driver requirement This patch update the version in [extras] section in setup.cfg Partial-Bug: #1871846 Change-Id: Iea45d041a1622216854614ca16ac6f3d0408f949
2022-08-31 15:28:18 +05:30
python-3parclient>=4.2.10 # Apache-2.0
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
krest>=1.3.0 # Apache-2.0
infinisdk>=103.0.1 # BSD-3
[Pure Storage] Fix minimum SDK version required Change method to check supported REST version on the backend. This will mkae it easier to specify minimum REST versions for specific feature support. Closes-Bug: #1929219 Change-Id: Ibab932d3536d44dd7414560768ed5bdeaa9e61e1
2021-05-20 13:36:58 -04:00
purestorage>=1.17.0 # BSD
Fix dfs-sdk package name in extra reqs This was causing a requirements repo cleanup script to not recognize the package was in use. Also adds a few missed extra packages to the All extra section. Change-Id: If4dfe5170f061ab2fa89b486ca1d09f5e719a679 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-05-08 06:07:22 -05:00
rsd-lib>=1.1.0 # Apache-2.0
StorPool: update the driver requirements. Bump the storpool module's version to 4.0.0 for various improvements and fixes. Add storpool.spopenstack at its current version 2.2.1. Add both storpool and storpool.spopenstack to setup.cfg and lower-constraints.txt. Change-Id: I2764e1a5f1ec8bbd878a7b2346722ec723889b22
2019-09-06 01:10:03 +03:00
storpool>=4.0.0 # Apache-2.0
storpool.spopenstack>=2.2.1 # Apache-2.0
Fix dfs-sdk package name in extra reqs This was causing a requirements repo cleanup script to not recognize the package was in use. Also adds a few missed extra packages to the All extra section. Change-Id: If4dfe5170f061ab2fa89b486ca1d09f5e719a679 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-05-08 06:07:22 -05:00
dfs-sdk>=1.2.25 # Apache-2.0
Add ceph iscsi volume driver The driver requires the new rbd-iscsi-client package, which is used to talk to the rbd-target-api on the ceph iscsi gateway node. The rbd-target-api is a python script meant to keep ceph iscsi gw nodes in sync with each other, but the API is works for creating iscsi targets. This is a new driver that makes heavy use of the ceph-iscsi project's rbd-target-api python REST client here: https://github.com/ceph/ceph-iscsi The driver is a derivation of the rbd driver, and the intention is to reuse as much of the base rbd driver as possible and just do iSCSI specific code here. Change-Id: Iff0e4d1137851c8f0b8ec25632d1186c2859b2fc
2019-06-03 19:07:09 +00:00
rbd-iscsi-client>=0.1.8 # Apache-2.0
Add install docs for LINSTOR driver dependencies Depends-On: Icfe13df75440eeaf6f5b1601f629c3230b119bb2 Change-Id: I4eadd5c06eac0b2361e56699385267ea6fb08374
2021-02-03 11:35:03 +01:00
python-linstor>=1.7.0 # LGPLv3
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
datacore =
Reintroduce DataCore driver Related-Blueprint: datacore-volume-cinder-driver Change-Id: I69228275fc36fb96c40fd219a9fb2f5d5e5b3cde
2022-04-07 21:49:49 +05:30
websocket-client>=1.3.2 # LGPLv2+
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
powermax =
pyOpenSSL>=17.5.0 # Apache-2.0
vnx =
storops>=0.5.10 # Apache-2.0
unity =
storops>=0.5.10 # Apache-2.0
fujitsu =
pywbem>=0.7.0 #LGPLv2.1+
hpe3par =
setup.cfg: [extras] for pip-installable driver requirement This patch update the version in [extras] section in setup.cfg Partial-Bug: #1871846 Change-Id: Iea45d041a1622216854614ca16ac6f3d0408f949
2022-08-31 15:28:18 +05:30
python-3parclient>=4.2.10 # Apache-2.0
Create extras for pypi install This patch adds a new [extras] to setup.cfg. This section contains support for drivers and their dependency requirements. This allows a user to pip install cinder and optionally install a driver's required pypi based library. For example, if you wanted to install cinder and support the 3PAR driver, you would use: pip install cinder[hpe3par] This installs all of the cinder requirements as well as the requirements for the hpe3par driver. The following drivers weren't added to the extras stanza rbd: No rados library in pypi drbd: There is no drbdmanage pypi package linstor: no python-linstor pypi package storpool: pypi package doesn't install in python3 env Change-Id: I2200ce6f554df0c988eb39521ce4defd75998a85
2019-05-02 00:30:27 -04:00
kaminario =
krest>=1.3.0 # Apache-2.0
ds8k =
pyOpenSSL>=17.5.0 # Apache-2.0
infinidat =
infinisdk>=103.0.1 # BSD-3
pure =
[Pure Storage] Fix minimum SDK version required Change method to check supported REST version on the backend. This will mkae it easier to specify minimum REST versions for specific feature support. Closes-Bug: #1929219 Change-Id: Ibab932d3536d44dd7414560768ed5bdeaa9e61e1
2021-05-20 13:36:58 -04:00
purestorage>=1.17.0 # BSD
Rsdlib changed providing_pools interface With the latest changes in the rsdlib in the RSD driver, The _get_providing_pool(self, volume) method is returning StoragePoolCollection instance, instead of StoragePool URL. Made code changes and corresponding unit tests to address this changes Change-Id: If7d24d2537deecd28400c120a23f3af172e92222 Closes-Bug: #1836121
2019-07-12 09:35:23 -07:00
rsd =
rsd-lib>=1.1.0 # Apache-2.0
StorPool: update the driver requirements. Bump the storpool module's version to 4.0.0 for various improvements and fixes. Add storpool.spopenstack at its current version 2.2.1. Add both storpool and storpool.spopenstack to setup.cfg and lower-constraints.txt. Change-Id: I2764e1a5f1ec8bbd878a7b2346722ec723889b22
2019-09-06 01:10:03 +03:00
storpool =
storpool>=4.0.0 # Apache-2.0
storpool.spopenstack>=2.2.1 # Apache-2.0
Update in-tree Datera Cinder driver New attempt to update Datera Cinder in-tree driver. This review request builds on https://review.opendev.org/#/c/661359/ with fixed zuul gating tests. Full list of changes since last update: * Added Pypi packaging installation support * Dropping support for v2 API. No Datera products exist in production with this API version. * Added v2.2 API support * Rewrite of the driver to use the Datera Python-SDK instead of hand-rolled connections. Usage requires the dfs_sdk python package * Dropping support for default_storage_name and default_volume_name volume-type keys * Added CHAP support * Implemented fast-path Glance-->Datera image cloning with clone_image RPC * Implemented fast-path volume retype * Rewrote unit tests from scratch * Added iops_per_gb and bandwidth_per_gb volume-type keys * Implemented update_migrated_volume * Increased number of stats reported with get_volume_stats * API fallback now only occurs during driver initialization. This increases driver performance * Added config option for customizing volume-type default values * Implemented template size override * Implemented LDAP support * Added support for filter_functions and goodness_functions * Changed version string to date-based * Implemented manage_existing_snapshot and related RPCs * Removed ancient py25 compatibility imports * Updated Copyright to 2020 * Fixed almost all requests From walter and Sean * Added comprehensive version history Change-Id: I56a1a24d60a7bc0dc59bfcfa89da23f43696a31e
2020-01-24 13:26:23 +00:00
datera =
Fix dfs-sdk package name in extra reqs This was causing a requirements repo cleanup script to not recognize the package was in use. Also adds a few missed extra packages to the All extra section. Change-Id: If4dfe5170f061ab2fa89b486ca1d09f5e719a679 Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2020-05-08 06:07:22 -05:00
dfs-sdk>=1.2.25 # Apache-2.0
Add ceph iscsi volume driver The driver requires the new rbd-iscsi-client package, which is used to talk to the rbd-target-api on the ceph iscsi gateway node. The rbd-target-api is a python script meant to keep ceph iscsi gw nodes in sync with each other, but the API is works for creating iscsi targets. This is a new driver that makes heavy use of the ceph-iscsi project's rbd-target-api python REST client here: https://github.com/ceph/ceph-iscsi The driver is a derivation of the rbd driver, and the intention is to reuse as much of the base rbd driver as possible and just do iSCSI specific code here. Change-Id: Iff0e4d1137851c8f0b8ec25632d1186c2859b2fc
2019-06-03 19:07:09 +00:00
rbd_iscsi =
rbd-iscsi-client>=0.1.8 # Apache-2.0
Add install docs for LINSTOR driver dependencies Depends-On: Icfe13df75440eeaf6f5b1601f629c3230b119bb2 Change-Id: I4eadd5c06eac0b2361e56699385267ea6fb08374
2021-02-03 11:35:03 +01:00
linstor =
python-linstor>=1.7.0 # LGPLv3
Rsdlib changed providing_pools interface With the latest changes in the rsdlib in the RSD driver, The _get_providing_pool(self, volume) method is returning StoragePoolCollection instance, instead of StoragePool URL. Made code changes and corresponding unit tests to address this changes Change-Id: If7d24d2537deecd28400c120a23f3af172e92222 Closes-Bug: #1836121
2019-07-12 09:35:23 -07:00
Add mypy tox env Add a "mypy" tox environment which runs mypy type checking against Cinder code. Taken from Stephen Finucane's Nova work at https://review.opendev.org/#/c/676208/ Added "show_error_codes" and "pretty" options. Generates an html report in ./mypy-report/ This adds stubs for oslo.i18n, so that _() calls are annotated as intended. It may be possible to do this with less .pyi files carried along here. Change-Id: I2589d22c1f16f2e177d34730a520591743c0c1e3
2020-05-18 16:58:16 -04:00
[mypy]
show_column_numbers = true
show_error_context = true
ignore_missing_imports = true
follow_imports = skip
incremental = true
check_untyped_defs = true
warn_unused_ignores = true
show_error_codes = true
pretty = true
html_report = mypy-report
mypy: set no_implicit_optional The current version of PEP-484 indicates that type checkers should not allow implicit optional parameters. - https://www.python.org/dev/peps/pep-0484/#union-types - https://github.com/python/mypy/issues/9091 Change-Id: I49e5729a4d754934e861d4d0fd25fd8b2a80602e
2022-02-11 11:57:25 -05:00
no_implicit_optional = true
Set packages in setup.cfg Without this, tox fails with an error: py38: FAIL code error: Multiple top-level packages discovered in a flat-layout: ['etc', 'roles', 'cinder', 'playbooks', 'releasenotes']. Change-Id: Iea13bca7b642ba0b0f1ffa38a504d5b6f2dd276b
2023-03-01 10:28:33 -05:00
[options]
packages = cinder
Copy Permalink