Release-announce

Download

release-announce@lists.openstack.org

October 2020

1 participants
201 discussions

cinder 16.2.0 (ussuri)
by no-reply＠openstack.org 02 Oct '20

02 Oct '20

We are jazzed to announce the release of: cinder 16.2.0: OpenStack Block Storage This release is part of the ussuri stable release series. The source is available from: https://opendev.org/openstack/cinder Download the package from: https://tarballs.openstack.org/cinder/ Please report issues through: https://bugs.launchpad.net/cinder/+bugs For more details, please see below. 16.2.0 ^^^^^^ Prelude ******* This release contains a partial fix for an upgrade issue. If you are upgrading a Train deployment of cinder to Ussuri, under specific circumstances you may need to take actions outside the normal upgrade process in order to accomplish a successful upgrade. In particular, there may be changes you must make in your Train deployment **before** you upgrade. See the "Upgrade Notes" and "Bug Fixes" sections of these release notes for details. The Cinder project team would like to point out some issues addressed by this release: * This release improves the handling of the "__DEFAULT__" volume- type (see "Other Notes", below) and fixes Bug #1879578 (https://bugs.launchpad.net/cinder/+bug/1879578) in which the default type was applied too aggressively (see the discussion of this issue in "Bug Fixes", below). * Operators affected by OSSN-0086 (https://wiki.openstack.org/wiki/OSSN/OSSN-0086) should note that this release updates the os-brick library used by cinder to version 3.0.3 in order to address an issue associated with the previous fixes for Bug #1823200 (https://bugs.launchpad.net/cinder/+bug/1823200) New Features ************ * This PowerMax driver moves the legacy shared volume from the masking view structure in Ocata and prior releases (when SMI-S was supported) to staging masking view(s) in Pike and later releases (U4P REST). In Ocata, the live migration process shared the storage group, containing the volume, among the different compute nodes. In Pike, we changed the masking view structure to facilitate a cleaner live migration process where only the intended volume is migrated without exposing other volumes in the storage group. The staging storage group and masking views facilitate a seamless live migration operation in upgraded releases. Known Issues ************ * Due to Bug #1893107 (https://bugs.launchpad.net/cinder/+bug/1893107) under specific circumstances, some operators may need to take actions outside the normal upgrade process to upgrade from Train to Ussuri. See the "Upgrade Notes" and "Bug Fixes" sections of these release notes for more details. Upgrade Notes ************* * The "default_volume_type" configuration option is now required to have a value. The default value is "__DEFAULT__", so you should see no change in behavior whether or not you have set a value for "default_volume_type". See Bug #1886632 (https://bugs.launchpad.net/cinder/+bug/1886632) for more information about this change. * This release partially fixes an upgrade issue (Bug #1893107 (https://bugs.launchpad.net/cinder/+bug/1893107)) that under some circumstances could prevent a cinder database upgrade from Train to Ussuri. The issue would occur if you had upgraded an unpurged Stein database to Train, and then attempted to upgrade the still unpurged database to Ussuri. If this describes your situation, please read further, because in order to avert this issue, there are some steps you may need to take in your **Train** deployment *before* you upgrade to Ussuri. This upgrade notice applies to you only if **all** of the following conditions are met: 1. You upgraded to Train from Stein 2. Before upgrading from Stein, you did **not** purge the cinder database 3. Your original upgrade from Stein was to cinder version 15.3.0 or earlier If all of the above apply to you, your upgrade path from Train to Ussuri is slightly more complicated than usual and may require some actions in your Train deployment *before* you upgrade. Please pick the least inconvenient of the following options: 1. Upgrade your Train deployment to cinder 15.4.0 or more recent and re-run the online database migrations in your Train deployment. * This migration requires the existence of a "__DEFAULT__" volume type. If you have renamed (or renamed and deleted) the "__DEFAULT__" volume type in Train, you must re-create it before running the online migrations. (If you renamed it, you don't have to un-rename it; you can create a new one just for the purposes of the online database migration.) If necessary, you can create a new "__DEFAULT__" volume type as follows using the Block Storage API, or by using the python- cinderclient or python-openstackclient to do the equivalent: API request: "POST /v3/{project_id}/types" Request body: { "volume_type": { "name": "__DEFAULT__", "description": "Default Volume Type", "os-volume-type-access:is_public": true } } The "__DEFAULT__" volume type may safely be renamed (or renamed and deleted) after you have run the online migrations as long as the "default_volume_type" configuration option is set to a valid existing volume type. * After the online database migrations from cinder 15.4.0 or more recent have run, you may upgrade to Ussuri in the normal way. 2. Upgrade to Ussuri, but run the online database migrations **before** you run the db_sync. (The normal ordering is to run db_sync first, and then run the online migrations.) * If you have renamed (or renamed and deleted) the "__DEFAULT__" volume type in Train, you must re-create it **in your Train deployment** before upgrading to Ussuri. This will ensure that the "__DEFAULT__" volume type will be present in the database when you run the Ussuri online database migrations. Use the directions above if you need to re-create the "__DEFAULT__" volume type. Once your Ussuri upgrade is completed, the "__DEFAULT__" volume type may safely be renamed (or renamed and deleted) as long as the "default_volume_type" configuration option is set to a valid existing volume type. 3. While in your Train deployment, purge the cinder database. This will remove soft-deleted volumes and snapshots and allow you to upgrade to Ussuri in the regular way. * This release updates the os-brick library used by Cinder to version 3.0.3 to correct hopefully the final problem with the fix for Bug #1823200 (https://bugs.launchpad.net/cinder/+bug/1823200) in the previous os-brick release. See the os-brick 3.0.3 release notes (https://docs.openstack.org/releasenotes/os- brick/ussuri.html#relnotes-3-0-3-stable-ussuri) for more information. Bug Fixes ********* * Bug #1886632 (https://bugs.launchpad.net/cinder/+bug/1886632) The system defined "__DEFAULT__" volume type is now treated as a regular volume-type and may be updated or deleted. Since the configured "default_volume_type" cannot be deleted, however, the "__DEFAULT__" volume type may not be deleted if it is the value of that configuration option. * Fix *UnboundLocalError* on the Brocade lookup driver on southbound client creation failure during the device mapping retrieval (Bug #1888550). * Add Python 3 support to the Brocade Zone Manager driver. (bug #1888548). * Fix *AttributeError* on the Brocade ZM driver when using setting REST_HTTP or REST_HTTPS as the fc_southbound_protocol option and an exception is raised by the client (Bug #1866860). * Fixed bug #1859652 (https://bugs.launchpad.net/cinder/+bug/1859652) to allow retyping an attached volume to SolidFire. * Cinder no longer allows an incremental backup to be created while having the parent backup in another project. * Fix bug #1874134 (https://bugs.launchpad.net/cinder/+bug/1874134) allowing an iSCSI or FCP volume to be extended to a size up to 16TB regardless of its original size, even if it's attached to an instance. * Bug #1879578 (https://bugs.launchpad.net/cinder/+bug/1879578) A regression in the Train release caused Cinder to assign the default volume type too aggressively when a volume type was not specified in a volume-create request. As a result, some alternative methods of specifying the volume type were ignored and the default type (either configured by the operator or the system default) would be assigned. This release restores the intended behavior, which is described as follows: If a "volume_type" is not specified when a volume is created, Cinder tries to infer the volume type from other information in the volume- create request: * if a "source_volid" is supplied in the request, the volume type is inferred from the source volume's volume type * if a "snapshot_id" is supplied in the request, the volume type is inferred from the volume type associated with the snapshot * if an "imageRef" is supplied in the request, and the image has a "cinder_img_volume_type" image property, the volume type is inferred from the value of that image property Otherwise, the volume type is the default volume type configured by the operator, and if no volume type is so configured, the volume type is the system default volume type, namely, "__DEFAULT__". When a volume type is specified explicitly in a volume-create call, Cinder will use the specified type. If the specified type cannot be assigned due to a conflict with other parameters in the volume- create call, however, the call will result in a 400 (Bad Request) response. * Bug #1887908 (https://bugs.launchpad.net/cinder/+bug/1887908)： In NEC driver, fix live-migration failure with FC. * Bug #1893107 (https://bugs.launchpad.net/cinder/+bug/1893107) The Ussuri release changes the cinder database schema to make the "volume_type_id" column in the "volumes" and "snapshots" tables non- nullable because all volumes have been required to have a volume type since the Train release. The online migration in cinder release 15.3.0 or earlier, however, did not process soft-deleted rows, leaving the possibility that there could be a deleted volume or snapshot with a null "volume_type_id", which in turn would make the database upgrade fail in Ussuri when the non-nullability constraint could not be applied. The issue is partially fixed in the current release ("partially" because in specific circumstances, an operator may need to take some actions outside the normal upgrade process). See the "Upgrade Notes" for more information. * Bug #1873738 (https://bugs.launchpad.net/cinder/+bug/1873738) RBD Driver: Added cleanup for residue destination file if the copy image to encrypted volume operation fails. * Fix HPE 3PAR driver issue where volumes that were live migrated to it would end up being inaccessible. We would no longer be able to use the volume for any operation, such as attach, detach, delete, snapshot, etc. (bug 1697422) * Fix "unique_fqdn_network" configuration option for the Kaminario driver, as it was being ignored when defined in the driver section, which used to work. (Bug #1886042). * Bug #1884268 (https://bugs.launchpad.net/cinder/+bug/1884268) Fixed issue where non-admin users could not show a volume transfer by name. * PowerMax Driver - Concurrent live migrations can sometimes fail when one thread deletes a storage group that another thread may need. * Fix revert to snapshot not working for non admin users when using the snapshot's name (bug #1889758). Other Notes *********** * Beginning with the Train release, untyped volumes (that is, volumes with no volume-type) have been disallowed. To facilitate this, a "__DEFAULT__" volume-type was included as part of the Train database migration. In this release, handling of the default volume-type has been improved: * The "default_volume_type" configuration option is required to have a value. The default value is "__DEFAULT__". * A request to delete the currently configured "default_volume_type" will fail. (You can delete that volume- type, but you cannot do it while it is the value of the configuration option.) * There must always be at least one volume-type defined in a Cinder installation. This is enforced by the type-delete call. * If the "default_volume_type" is misconfigured (that is, if the value refers to a non-existent volume-type), requests that rely on the default volume-type (for example, a volume-create request that does not specify a volume-type) will result in a HTTP 500 response. Changes in cinder 16.1.0..16.2.0 -------------------------------- 53d482275 Add general release note for 16.2.0 3906b51df PowerMax Driver - Failover group vol update fix b7f9a7455 PowerMax Driver - Force add rep group volume b46f5becd Modify default/delete volume type logic 05c7b77d8 PowerMax Ussuri Docs - Upgrade improvement notification c55e259d5 NEC driver: fix live-migration failure with FC 7a20d32e8 Require os-brick >= 3.0.3 f29e884b2 Include deleted volumes for online data migrations d51dc099a Fix revert to snapshot for non admins b8c6fcb1b Fix: show volume transfer by name for non-admins 07991b7e8 PowerMax Driver - Legacy volumes fail to live migrate 0471fab34 Remove unnecessary releasenote dae548d54 Correct formatting in release note 41fcbf8a5 Brocade: Fix lookup UnboundLocalError 373efbd7e Brocade: Fix AttributeError when raising exception 297c8b078 Brocade: Python 3 support f23c7e8f8 Creating snapshot on NFS backend fails 2058cde4d Fix rekeying volume with legacy encryption provider 4ee343044 PowerMax Driver - Volume Migrate Exception Handling 02de7897d RBD: Cleanup temporary file during exception b584cb95b zuul: collect cinderlib logs from tempest node(s) only 33cf05eba Kaminario: Fix unique_fqdn_network option daf45b986 PowerMax Driver - Create vol suspend fix & DeviceID check cc0c69bd5 PowerMax Driver - Rep validation fix & Retype suspension fix 72846a194 Disable siblings for the cinderlib functional tests c1bdb233c Default volume_type set too early 5358c996b Fix cross-project incremental backups 3fadd92b6 PowerMax Ussuri Driver - Setting the minimum version of U4P 143ce911b PowerMax Driver - Ussuri Documentation 0f6b4cdcd Fix service-get-log to respect server filters 8c55df95d NetApp ONTAP: Fix extend volume for iSCSI/FCP 408531cf2 3PAR: Fix live migration eb7b8da89 Fixed issues with Pure syncrep iSCSI CIDRs cf5eaae59 Native Zuul v3 cinder-grenade jobs 9561882bd PowerMax Driver - Live migrate remove rep vol from sg 13e45234b PowerMax Driver - U4P failover lock not released on exception f6686741e PowerMax Driver - Concurrent live migrations failure 0a223ff59 NetApp SolidFire: Fix retype to SolidFire Diffstat (except docs and test files) ------------------------------------- .zuul.yaml | 119 +- cinder/api/contrib/services.py | 13 +- cinder/api/contrib/types_manage.py | 10 +- cinder/api/v2/volumes.py | 17 +- cinder/api/v3/volumes.py | 19 +- cinder/backup/api.py | 5 +- cinder/common/config.py | 2 + cinder/db/api.py | 4 +- cinder/db/sqlalchemy/api.py | 15 +- cinder/exception.py | 16 +- cinder/image/image_utils.py | 4 + cinder/objects/backup.py | 6 +- cinder/test.py | 22 + .../drivers/dell_emc/powermax/powermax_data.py | 15 +- .../dell_emc/powermax/test_powermax_common.py | 298 ++++- .../dell_emc/powermax/test_powermax_masking.py | 40 +- .../dell_emc/powermax/test_powermax_migrate.py | 512 +++++++++ .../dell_emc/powermax/test_powermax_replication.py | 315 +++++- .../dell_emc/powermax/test_powermax_rest.py | 19 +- .../netapp/dataontap/client/test_client_base.py | 157 ++- .../netapp/dataontap/client/test_client_cmode.py | 2 + .../unit/volume/drivers/netapp/dataontap/fakes.py | 17 + .../drivers/netapp/dataontap/test_block_base.py | 117 +- .../drivers/netapp/dataontap/test_block_cmode.py | 4 +- .../volume/drivers/solidfire/test_solidfire.py | 29 + .../unit/volume/flows/api/test_create_volume.py | 208 ++++ .../unit/volume/flows/test_create_volume_flow.py | 144 ++- .../zonemanager/test_brcd_fc_san_lookup_service.py | 10 + .../unit/zonemanager/test_brcd_fc_zone_driver.py | 137 ++- .../zonemanager/test_brcd_http_fc_zone_client.py | 7 + .../zonemanager/test_brcd_rest_fc_zone_client.py | 298 +++++ cinder/transfer/api.py | 6 +- cinder/volume/api.py | 7 +- cinder/volume/drivers/dell_emc/powermax/common.py | 1156 ++++++++++++++------ cinder/volume/drivers/dell_emc/powermax/fc.py | 11 +- cinder/volume/drivers/dell_emc/powermax/iscsi.py | 11 +- cinder/volume/drivers/dell_emc/powermax/masking.py | 98 +- cinder/volume/drivers/dell_emc/powermax/migrate.py | 423 +++++++ cinder/volume/drivers/dell_emc/powermax/rest.py | 33 +- cinder/volume/drivers/dell_emc/powermax/utils.py | 5 +- cinder/volume/drivers/hpe/hpe_3par_common.py | 309 ++++-- cinder/volume/drivers/hpe/hpe_3par_fc.py | 4 +- cinder/volume/drivers/hpe/hpe_3par_iscsi.py | 12 +- .../volume/drivers/kaminario/kaminario_common.py | 5 +- cinder/volume/drivers/nec/volume_helper.py | 8 +- .../volume/drivers/netapp/dataontap/block_base.py | 23 +- .../volume/drivers/netapp/dataontap/block_cmode.py | 2 +- .../volume/drivers/netapp/dataontap/client/api.py | 6 + .../drivers/netapp/dataontap/client/client_base.py | 55 +- .../netapp/dataontap/client/client_cmode.py | 2 + cinder/volume/drivers/pure.py | 50 +- cinder/volume/drivers/rbd.py | 15 +- cinder/volume/drivers/remotefs.py | 3 +- cinder/volume/drivers/solidfire.py | 9 +- cinder/volume/flows/api/create_volume.py | 50 +- cinder/volume/volume_types.py | 54 +- cinder/volume/volume_utils.py | 1 + .../drivers/brocade/brcd_fc_san_lookup_service.py | 1 + .../drivers/brocade/brcd_fc_zone_driver.py | 13 +- .../drivers/brocade/brcd_http_fc_zone_client.py | 2 +- .../drivers/brocade/brcd_rest_fc_zone_client.py | 2 +- .../drivers/dell-emc-powermax-driver.rst | 1124 ++++++++++++------- .../block-storage/drivers/hpe-3par-driver.rst | 3 +- lower-constraints.txt | 2 +- .../grenade-dsvm-cinder-mn-sub-bak/post.yaml | 15 - .../legacy/grenade-dsvm-cinder-mn-sub-bak/run.yaml | 53 - .../grenade-dsvm-cinder-mn-sub-volbak/post.yaml | 15 - .../grenade-dsvm-cinder-mn-sub-volbak/run.yaml | 53 - .../grenade-dsvm-cinder-mn-sub-volschbak/post.yaml | 15 - .../grenade-dsvm-cinder-mn-sub-volschbak/run.yaml | 54 - playbooks/post-cinderlib.yaml | 2 +- playbooks/tempest-and-cinderlib-run.yaml | 1 + ...deleting-__DEFAULT__-type-d35dfb5d89760b9b.yaml | 38 + ...ade_looup_fail_get_client-179151d449a34aa4.yaml | 5 + .../notes/brocade_py3-15647dbe3981d44b.yaml | 5 + .../brocade_rest_client-202cfd474c96d3fe.yaml | 6 + ...ached-volume-to-solidfire-1933f03673ff078d.yaml | 5 + ...746-cross-project-incremental-backup-error.yaml | 6 + ...ONTAP-fix-max-resize-size-ad2d88da8721560e.yaml | 6 + ...70-nfs-image-volume-cache-c45e840a6ec2a702.yaml | 2 +- ...78-volume_type-regression-de82f4152c7b2f77.yaml | 33 + ...-migration-failure-withfc-3128fff7c48e739f.yaml | 6 + .../notes/bug-1893107-ussuri-03765453337a7909.yaml | 114 ++ ...-file-during-convert-fail-3848e9dbe7e15fc6.yaml | 6 + .../fix-3par-live-migration-0065bd2626fdb4a1.yaml | 7 + ...nario-unique_fqdn_network-ecde36f614c30733.yaml | 7 + ...w-transfer-for-non-admins-be001d79975b325d.yaml | 5 + .../notes-for-16.2.0-release-1a9ea167c778eeaa.yaml | 29 + .../powermax-auto-migration-5cc57773c23fef02.yaml | 13 + .../powermax-bug-1875478-8c9072ad9a87b83d.yaml | 5 + ...revert-snapshot-non-admin-8485be55060eab0d.yaml | 5 + requirements.txt | 2 +- 115 files changed, 6041 insertions(+), 1776 deletions(-) Requirements updates -------------------- diff --git a/requirements.txt b/requirements.txt index 45cc5370c..15907e5d6 100644 --- a/requirements.txt +++ b/requirements.txt @@ -58 +58 @@ oslo.vmware>=2.35.0 # Apache-2.0 -os-brick>=3.0.2 # Apache-2.0 +os-brick>=3.0.3 # Apache-2.0

1 0

Jump to page: