<div dir="ltr">Thanks Brian and Ghanshyam for the discussion. I've updated the tempest patch[1] to update one test that I missed earlier and also the cinder patch[2] which now returns a BadRequest stating the reason for the error and how to fix it.<div><br></div><div>$ curl -g -i -X POST <a href="http://127.0.0.1/volume/v3/d6634f35c00f409883ecb10361b556c3/volumes">http://127.0.0.1/volume/v3/d6634f35c00f409883ecb10361b556c3/volumes</a> -H "Accept: application/json" -H "Content-Type: application/json" -H "User-Agent: python-cinderclient" -H "X-Auth-Token: gAAAAABkAbZkWgdbpXNgObizvGy8jS6LoMGuxzMnMaMOw6wm2j5i5KrG2xIzWCDxrSAiaMJWqneNpKrwn8P852mPOyJB_WmxrhrmKiuafcP0KSljyW44mFwDtGN74VL50NLoVC-srL63L3xduyeF5EIlPEyDsWRqPSRZZwau7wQrngAZ8XBP3M8" -d '{"volume": {"size": 1, "consistencygroup_id": null, "snapshot_id": null, "name": null, "description": null, "volume_type": null, "availability_zone": null, "metadata": {}, "imageRef": null, "source_volid": null, "backup_id": null, "multiattach": "true"}}'<br>HTTP/1.1 400 Bad Request<br>Date: Fri, 03 Mar 2023 09:04:38 GMT<br>Server: Apache/2.4.41 (Ubuntu)<br>OpenStack-API-Version: volume 3.0<br>Vary: OpenStack-API-Version<br>Content-Length: 261<br>Content-Type: application/json<br>x-compute-request-id: req-a9f9999e-01e3-4970-9c32-35de193c04c1<br>x-openstack-request-id: req-a9f9999e-01e3-4970-9c32-35de193c04c1<br>Connection: close<br><br>{"badRequest": {"code": 400, "message": "multiattach parameter has been removed. The default behavior is to use multiattach enabled volume types. Contact your administrator to create a multiattach enabled volume type and use it to create multiattach volumes."}}<br><div><br></div><div>[1] <a href="https://review.opendev.org/c/openstack/tempest/+/875372">https://review.opendev.org/c/openstack/tempest/+/875372</a></div></div><div>[2] <a href="https://review.opendev.org/c/openstack/cinder/+/874865">https://review.opendev.org/c/openstack/cinder/+/874865</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 3, 2023 at 9:00 AM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com">gmann@ghanshyammann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ---- On Thu, 02 Mar 2023 19:17:32 -0800  Brian Rosmaita  wrote --- <br>
 > On 3/1/23 12:19 PM, Ghanshyam Mann wrote:<br>
 > >   ---- On Wed, 01 Mar 2023 09:02:59 -0800  Brian Rosmaita  wrote ---<br>
 > >   > On 2/28/23 9:02 PM, Ghanshyam Mann wrote:<br>
 > >   > [snip]<br>
 > >   ><br>
 > >   > > I think removing from client is good way to stop exposing this old/not-recommended way to users<br>
 > >   > > but API is separate things and removing the API request parameter 'multiattach' from it can break<br>
 > >   > > the existing users using it this way. Tempest test is one good example of such users use case. To maintain<br>
 > >   > > the backward compatibility/interoperability it should be removed by bumping the microversion so that<br>
 > >   > > it continue working for older microversions. This way we will not break the existing users and will<br>
 > >   > > provide the new way for users to start using.<br>
 > >   ><br>
 > >   > It's not just that this is not recommended, it can lead to data loss.<br>
 > >   > We should only allow multiattach for volume types that actually support<br>
 > >   > it.  So I see this as a case of "I broke your script now, but you'll<br>
 > >   > thank me later".<br>
 > >   ><br>
 > >   > We could microversion this, but then an end user has to go out of the<br>
 > >   > way and add the correct mv to their request to get the correct behavior.<br>
 > >   >   Someone using the default mv + multiattach=true will unknowingly put<br>
 > >   > themselves into a data loss situation.  I think it's better to break<br>
 > >   > that person's API request.<br>
 > > <br>
 > > Ok, if multiattach=True in the request is always an unsuccessful case (or unknown successful sometimes)<br>
 > > then I think changing it without microversion bump makes sense. But if we know there is any success case<br>
 > > for xyz configuration/backend then I feel we should not break such success use case.<br>
 > <br>
 > Thanks, Ghanshyam.  An end user is setting themselves up for data loss <br>
 > if they rely on the request parameter rather than on using a volume type <br>
 > that explicitly supports multiattach.  They could get lucky and not lose <br>
 > any data, but that's not really a success, so I think the best thing to <br>
 > do here is make this breaking change without a microversion.<br>
 > <br>
 > > I was just thinking from the Tempest test perspective which was passing but as you corrected me in IRC,<br>
 > > the test does not check the data things so we do not completely test it in Tempest.<br>
 > <br>
 > It's good that Tempest is there to keep us honest!  I think what we can <br>
 > do to help out people whose scripts break is to return a specific error <br>
 > message explaining that the 'multiattach' element is not allowed in a <br>
 > volume-create request and instead the user should select a <br>
 > multiattach-capable volume type.<br>
<br>
Thanks, Brian for explaining. This sounds good to me. Explaining the situation in release notes and error message<br>
will be really helpful for users.<br>
<br>
 I am +2 on the tempest change now - <a href="https://review.opendev.org/c/openstack/tempest/+/875372" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/tempest/+/875372</a><br>
<br>
-gmann<br>
<br>
 > <br>
 > > <br>
 > > -gmann<br>
 > > <br>
 > >   ><br>
 > >   ><br>
 > >   > cheers,<br>
 > >   > brian<br>
 > >   ><br>
 > >   ><br>
 > >   ><br>
 > <br>
 > <br>
 > <br>
<br>
</blockquote></div>