inconsistency between trove api schema and code for edit() request

[Amrith Kumar]

The apischema indicate that the edit() request has a structure of:

   294 "edit": {
   295 "name": "instance:edit",
   296 "type": "object",
   297 "required": ["instance"],
   298 "properties": {
   299 "instance": {
   300 "type": "object",
   301 "required": [],
   302 "properties": {
   303 "slave_of": {},
   304 "name": non_empty_string,
   305 "configuration_id": configuration_id,
   306 }
   307 }
   308 }
   309 },

The code however uses "configuration" and not "configuration_id". However, since no properties are required and additional properties are allowed, the client gets away by specifying "configuration" and the API service looks for that.

   296 def edit(self, req, id, body, tenant_id):
   297 """
   298 Updates the instance to set or unset one or more attributes.
   299 """
   300 LOG.info(_LI("Editing instance for tenant id %s."), tenant_id)
   301 LOG.debug("req: %s", strutils.mask_password(req))
   302 LOG.debug("body: %s", strutils.mask_password(body))
   303 context = req.environ[wsgi.CONTEXT_KEY]
   304
   305 instance = models.Instance.load(context, id)
   306
   307 args = {}
   308 args['detach_replica'] = 'slave_of' in body['instance']
   309 if 'name' in body['instance']:
   310 args['name'] = body['instance']['name']
   311 if 'configuration' in body['instance']:
   312 args['configuration_id'] = self._configuration_parse(context, body)
   313 self._modify_instance(instance, **args)
   314 return wsgi.Result(None, 202)

DEBUG (session:195) REQ: curl -g -i --cacert "/opt/stack/data/CA/int-ca/ca-chain.pem" -X PATCH http://192.168.117.5:8779/v1.0/70195ed77e594c63b33c5403f2e2885c/instances/c399c99a-ee17-4048-bf8b-0ea5c36bb1cb -H "User-Agent: python-keystoneclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-Auth-Token: {SHA1}d70565f3d39b1e0c10ae5e667a1d6395e073507f" -d '{"instance": {"configuration": "3226b8e6-fa38-4e23-a4e6-000b639a93d7"}}'

If I forced validation of the schema

diff --git a/trove/common/apischema.py b/trove/common/apischema.py
index ae6f4c1..63e128c 100644
--- a/trove/common/apischema.py
+++ b/trove/common/apischema.py
@@ -299,6 +299,7 @@ instance = {
             "instance": {
                 "type": "object",
                 "required": [],
+ "additionalProperties": False,
                 "properties": {
                     "slave_of": {},
                     "name": non_empty_string,

and re-ran the trove update command, it fails!

ubuntu@trove-book:/opt/stack/trove$ trove update new-m1 --configuration 3226b8e6-fa38-4e23-a4e6-000b639a93d7
ERROR: Validation error: instance Additional properties are not allowed (u'configuration' was unexpected) (HTTP 400)

[Amrith Kumar (amrith)]

I upp'ed this to High because the parameter "configuration" that we use is not part of the schema and therefore most of the tests (which exercise the validator) fail. That's because the API is also used to unassign a configuration from an instance but the schema doesn't quite allow that ;(

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/186992

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/186992
Committed: https://git.openstack.org/cgit/openstack/trove/commit/?id=ddb9b7da0390474aa15290deb33e16c8c2ef49e8
Submitter: Jenkins
Branch: master

commit ddb9b7da0390474aa15290deb33e16c8c2ef49e8
Author: Amrith Kumar <email address hidden>
Date: Thu May 28 22:13:16 2015 -0400

    correct api schema for instance patch

    The api schema specification for the patch oepration is in error and
    defined a parameter of "configuration_id" while the code (both in the
    server and the client, and also all the tests) used "configuration".

    A fix with fewer lines of code would have been to just embed the {
    "type": "null" } into the definition of configuration_id but I am
    going to be making additional changes to the way in which we signal
    (through a put call) that we want to detach a configuration_id so I've
    defined a null_configuration_id type which I can use there as
    well.

    To prevent this from reoccuring, additionalProperties has been set to
    False.

    Change-Id: Ic98050e487b0d8cd9a68e8c46169456a52e2b16c
    Closes-Bug: #1460174