Open Stack

On Tue, Aug 07, 2018 at 05:27:06PM -0500, Monty Taylor wrote:
> On 08/07/2018 05:03 PM, Akihiro Motoki wrote:
> >Hi Cinder and API-SIG folks,
> >
> >During reviewing a horizon bug [0], I noticed the behavior of Cinder API
> >3.0 was changed.
> >Cinder introduced more strict schema validation for creating/updating
> >volume encryption type
> >during Rocky and a new micro version 3.53 was introduced[1].
> >
> >Previously, Cinder API like 3.0 accepts unused fields in POST requests
> >but after [1] landed unused fields are now rejected even when Cinder API
> >3.0 is used.
> >In my understanding on the microversioning, the existing behavior for
> >older versions should be kept.
> >Is it correct?
> 
> I agree with your assessment that 3.0 was used there - and also that I would
> expect the api validation to only change if 3.53 microversion was used.
> 

I filed a bug to track this:

https://bugs.launchpad.net/cinder/+bug/1786054

But something doesn't seem right from what I've seen. I've put up a patch to
add some extra unit testing around this. I expected some of those unit tests to
fail, but everything seemed happy and working the way it is supposed to with
prior to 3.53 accepting anything and 3.53 or later rejecting extra parameters.

Since that didn't work, I tried reproducing this against a running system using
curl. With no version specified (defaulting to the base 3.0 microversion)
creation succeeded:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H
"Accept: "Content-Type: application/json" -H "User-Agent: python-cinderclient"
-H "X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}'

I then tried specifying the microversion that introduces the strict schema
checking to make sure I was able to get the appropriate failure, which worked
as expected:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H
"Accept: "Content-Type: application/json" -H "User-Agent: python-cinderclient"
-H "X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New-mv353", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}' -H "OpenStack-API-Version: volume 3.53"
HTTP/1.1 400 Bad Request
...

And to test boundary conditions, I then specified the microversion just prior
to the one that enabled strict checking:

curl -g -i -X POST
http://192.168.1.234/volume/v3/95ae21ce92a34b3c92601f3304ea0a46/volumes -H "Ac
"Content-Type: application/json" -H "User-Agent: python-cinderclient" -H
"X-Auth-Token: $OS_TOKEN" -d '{"volume": {"backup_id": null, "description":
null, "multiattach": false, "source_volid": null, "consistencygroup_id": null,
"snapshot_id": null, "size": 1, "name": "New-mv352", "imageRef": null,
"availability_zone": null, "volume_type": null, "metadata": {}, "project_id":
"testing", "junk": "garbage"}}' -H "OpenStack-API-Version: volume 3.52"
HTTP/1.1 202 Accepted

In all cases except the strict checking one, the volume was created
successfully even though the junk extra parameters ("project_id": "testing",
"junk": "garbage") were provided.

So I'm missing something here. Is it possible horizon is requesting the latest
API version and not defaulting to 3.0?

Sean