Bug 2004214
| Summary: | NetApp ONTAP cannot resize a volume LUN with sub-clone | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Eduardo Santos <edacosta> |
| Component: | openstack-cinder | Assignee: | Cinder Bugs List <cinder-bugs> |
| Status: | CLOSED ERRATA | QA Contact: | Luigi Toscano <ltoscano> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 13.0 (Queens) | CC: | abishop, brian.rosmaita, eharney, eshames, fabioaurelio1269, ifrangs, jelynch, kgilliga, ltoscano, nahimsouza, schhabdi |
| Target Milestone: | z6 | Keywords: | OtherQA, Triaged, ZStream |
| Target Release: | 16.2 (Train on RHEL 8.4) | ||
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-cinder-15.6.1-2.20230906144854.299553a.el8ost | Doc Type: | Bug Fix |
| Doc Text: |
This update fixes a NetApp Block Storage (cinder) volume driver issue. Previously, a volume extend operation could fail when the extended size was greater than the maximum LUN geometry on the back end due to a malformed request from the driver. The driver now includes the correct information in the request.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-08 19:18:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Eduardo Santos
2021-09-14 17:50:30 UTC
(In reply to Eduardo Santos from comment #0) > Hi, > > When trying to create a clone using Cinder with Netapp driver on OpenStack > we encountered the following error: > > Cannot set space reservation for block ranges. :: ONTAPI :: Error > > This happens when trying to create a clone with snapshot of size larger than > 2 TB, with the block ranges are being specified in the clone creation > request. > > Whereas, when trying to create a clone with snapshot of size smaller than 2 > TB, the cloning request is coming to the storage without the block range > specified and it completes successfully. > > A bug report was already filed on Cinder's Launchpad [1] and a change has > already been proposed to address the issue [2]. > > Rocky or older (including Queens) OpenStack releases are affected. Please note that Red Hat OpenStack Platform 13 (based on Queens) is now in Extended Lifecycle Support (ELS) state, where only a limited amount of fix is applied, please check: https://access.redhat.com/support/policy/updates/openstack/platform Is this bug (while waiting for the fix to be merged in opendev.org) still relevant for OSP13, or can it be targeted to the more recent 16.x releases? (In reply to Luigi Toscano from comment #1) > (In reply to Eduardo Santos from comment #0) > > Hi, > > > > When trying to create a clone using Cinder with Netapp driver on OpenStack > > we encountered the following error: > > > > Cannot set space reservation for block ranges. :: ONTAPI :: Error > > > > This happens when trying to create a clone with snapshot of size larger than > > 2 TB, with the block ranges are being specified in the clone creation > > request. > > > > Whereas, when trying to create a clone with snapshot of size smaller than 2 > > TB, the cloning request is coming to the storage without the block range > > specified and it completes successfully. > > > > A bug report was already filed on Cinder's Launchpad [1] and a change has > > already been proposed to address the issue [2]. > > > > Rocky or older (including Queens) OpenStack releases are affected. > > Please note that Red Hat OpenStack Platform 13 (based on Queens) is now in > Extended Lifecycle Support (ELS) state, where only a limited amount of fix > is applied, please check: > https://access.redhat.com/support/policy/updates/openstack/platform > > Is this bug (while waiting for the fix to be merged in opendev.org) still > relevant for OSP13, or can it be targeted to the more recent 16.x releases? Hi Luigi, we understand that it's relevant for OSP13 because though some of our customers already use OSP16, most of them still use OSP13 and they can have problems in some basic functions like cloning and extending volumes. Posting public comment (most of the private comments in this BZ do not need to be private). Also responding for Tosky, who is on PTO. Netapp has posted a patch upstream, and it has a couple of +1 votes. It it Netapp's responsibility for advocating for additional reviews, especially from core reviewers. This can be done in the #openstack-cinder irc channel, or in the weekly cinder meeting (also on irc). A good way of prompting for reviewers is to mention the patch is in a good state (all comments addressed, and CI passed), and customers are waiting for the fix. However, looking at the upstream gerrit results indicate Netapp's own CI isn't passing. Netapp needs to monitor the situation, and take the steps to get it working. Core reviewers will not approve driver patches unless the driver's own CI tests are passing. Once the patch has merged on upstream master, upstream backports need to be posted sequentially for all relevant upstream releases (xena, wallaby, victoria, ussuri, train, etc.). Hello, we got the patch merged into master and now we are working on the backports https://review.opendev.org/c/openstack/cinder/+/798208 Hello, Backports to Xena (https://review.opendev.org/c/openstack/cinder/+/821890) and Wallaby (https://review.opendev.org/c/openstack/cinder/+/821892) already got merged. We will provide a manual QA as a requirement to merge this bugfix on the remaining stable branches until Train. Added suggested documentation. 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 16.2.6 (Train) 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-2023:6307 |