Created attachment 1287617 [details] Example of setting both 'size' and 'provisioned_size' values to a Disk object in V3 API Description of problem: When assigning both 'size' and 'provisioned_size' values to a 'params.Disk' object using sdk (order doesn't matter), the disk's size as it appears on the UI is determined by the 'provisioned_size', without showing any error message or other feedback to the user. Version-Release number of selected component (if applicable): Reproduced for 4.2 version, although according to the code, was probably present before that. How reproducible: 100% Steps to Reproduce: 1. Create a disk using the REST API V3 or SDK with both 'size' and 'provisioned_size' parameters. Actual results: The disk's size is determined by the 'provisioned_size' parameter, without any errors. Expected results: Error / notification Additional info: -
Looking at V3DiskInAdapter, size is handled first and provisioned_size is handled later, both calling the result's setSize. Juan - what's the right approach here? Throw and exception if both size and provisioned_size are set? Document this behavior? If so, where?
That logic is there to preserve backwards compatibility. When the 'provisioned_size' attribute was introduced the 'size' attribute couldn't be removed, because that would have broken backwards compatibility for applications that were already sending it. We can't fail if both are sent, because a common practice is to do updates retrieving the object, modifying it, and sending it back to do the update. That will send both 'size' and 'provisioned_size' even when updating something else. That behaviour is the default in version 3 of the SDKs, for example. We don't have documentation for version 3 of the API, so the only possible place to document this is the documentation of version 4 of the API. We could add a note to the description of 'provisioned_size' explaining this, although we don't usually explain V3 behaviours in V4 behaviours. This BZ may be the best place to explain it. In that case it is already done.
Thanks for the extensive explanation Juan! I agree, let's close this BZ.