Bug 1940153 - [OSP13] HP Cinder driver convert_to_base option is forced to true creating unnecessary volume
Summary: [OSP13] HP Cinder driver convert_to_base option is forced to true creating un...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z16
: 13.0 (Queens)
Assignee: Pablo Caruana
QA Contact: Tzach Shefi
Andy Stillman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-03-17 17:19 UTC by ggrimaux
Modified: 2024-06-14 00:52 UTC (History)
10 users (show)

Fixed In Version: openstack-cinder-12.0.10-22.el7ost
Doc Type: Bug Fix
Doc Text:
Before this update, when using the Block Storage service (cinder) to create a large number of instances (bootable volumes) from snapshots on HP3Par Storage back end servers, timeouts occurred. An HP variable (`convert_to_base`) was set to true which caused HP3Par to create a thick volume of the original volume. This was an unnecessary and unwanted action. + With this update, a newer HP driver (4.0.11) has been backported to RHOSP 13 that includes a new spec: + ---- hpe3par:convert_to_base=True | False ---- + * True (default) - The volume is created independently from the snapshot (HOS8 behavior). * False - The volume is created as a child of snapshot (HOS5 behavior). + .Usage + You can set this new spec for HPE3Par volumes by using the `cinder type-key` command: + ---- cinder type-key <volume-type-name-or-ID> set hpe3par:convert_to_base=False | True ---- + .Example + ---- $ cinder type-key myVolType set hpe3par:convert_to_base=False $ cinder create --name v1 --volume-type myVolType 10 $ cinder snapshot-create --name s1 v1 $ cinder snapshot-list $ cinder create --snapshot-id <snap_id> --volume-type myVolType --name v2 10 ---- + .Notes If the size of v2 is greater than size of v1, then the volume cannot be grown. In this case, to avoid any error, v2 is converted to a base volume (`convert_to_base=True`).
Clone Of:
Environment:
Last Closed: 2021-06-16 10:59:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1814027 0 None None None 2021-03-17 18:28:25 UTC
OpenStack gerrit 781798 0 None NEW 3PAR: Provide an option duing creation of volume from snapshot 2021-03-31 10:48:20 UTC
Red Hat Issue Tracker OSP-460 0 None None None 2022-10-03 14:44:57 UTC
Red Hat Product Errata RHBA-2021:2385 0 None None None 2021-06-16 11:00:22 UTC

Description ggrimaux 2021-03-17 17:19:12 UTC
Description of problem:
Setup:
OSP13z10
HP3Par Storage backend

Goal: 
Do backup of volumes

Operation:
#1 Create a snapshot of a volume
#2 Create a volume of that snapshot


On the HP3Par storage we see 3 operations:
#1 Create the snapshot
#2 Create a separate thick volumes (createvvcopy in HP terms) of the original volume that is never used after
#3 Create a vlun to attach to the compute node

That extra step (#2) is not needed or wanted.

We discovered why this is happening. 
Its because of the HP variable called 'convert_to_base'.
On OSP13 even with the latest z release (z14) the HP driver included is 4.0.8.

In that version convert_to_base is set to True. There is no way to force it to false.

That is why in version 4.0.11 an extra spec has been created to allow openstack to interact with that variable and they also made that variable false by default.

In OSP16.1 We do have this new version and it works as advertise and it solved the problem I am describing above.

The request here is to backport 4.0.11 HP driver version to OSP13.



Version-Release number of selected component (if applicable):
OSP13 (any release)
HP Driver 4.0.8

How reproducible:
100%

Steps to Reproduce:
1. Create snapshot of volume
2. Create volume of that snapshot
3. Wait several hours to have volumes created.

Actual results:
Unnecessary step of creating a volume that is not used or needed.

Expected results:
Removed that extra step.

Additional info:

Comment 1 Alan Bishop 2021-03-17 18:28:27 UTC
@Pablo, can you take this?

Comment 6 spower 2021-04-13 18:57:41 UTC
Exception flag granted

Comment 22 errata-xmlrpc 2021-06-16 10:59:46 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Red Hat OpenStack Platform 13.0 bug fix and enhancement advisory), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:2385


Note You need to log in before you can comment on or make changes to this bug.