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. Steps to reproduce: 1. Deploy a queens release 2. Configure ONTAP 9.3 3. Create a volume smaller than 64G (e.g. openstack volume create --size 4 test) 4. Try to extend the volume to larger than 64G (e.g. openstack volume set test --size 65) Actual result: Volume is in error_extending state, and c-vol logs an error: http://paste.openstack.org/show/804536/ Expected result: Volume is extended to the specified size (e.g. volume 'test' would be 65G) [1] https://bugs.launchpad.net/cinder/+bug/1924643 [2] https://review.opendev.org/c/openstack/cinder/+/798208
(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