Description of problem: In Queens, the ability to create a multiattach volume by including a request parameter in the volume-create request was deprecated in favor of using a multiattach volume-type. The former operation is dangerous and can lead to data loss. Since Rocky, the cinderclient and openstackclient have not allowed a multiattach request parameter, but unfortunately it was not removed from the API until the Antelope release. Because there were existing tempest tests around the deprecated feature, these had to be revised, and the changes were accepted by the upstream QA team because this is a data loss issue. A customer noticed the upstream cinder change and requested that it be backported to RHOSP 16.2; since the backport will break existing tempest tests in 17 and 16, the tempest patch needs to be backported too. Additional info: A complication is that volume-type creation is an admin-only operation, whereas requesting the creation of a multiattach volume (i.e., a volume of a multiattach volume-type) can be done with non-admin credentials. The upstream QA team wanted to leave the multiattach tests in the non-admin realm, so the appropriate volume-type is created upstream in devstack. We'll have to create it in infrared.
Moving 2184834 BZ from being dependent on to blocked by this - 2184834 stops supporting the "old way", therefore this tempest change has to be backported first (as it stops using the "old way")
The Fixed in version package doesn't contain any "old way" use -> no multiattach=True arguments. Moving to VERIFIED.
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 (Release of components for Red Hat OpenStack Platform 17.1 (Wallaby)), 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/RHEA-2023:4577