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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
