Bug 1597382

Description of problem:

The settings API will revert changes when more than a single API call to the settings endpoint is specified.  Only the last change that was PATCH'd to the API is kept.  Here is an example, with commands, showing this behavior:

# get the server name
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | grep name

...
        "name": "EVM",
...


# update the server name (server name is appropriately updated)
curl -X PATCH -u 'admin:smartvm' -d "{\"server\":{\"name\":\"cfme-02\"}}" 'https://192.168.50.184/api/servers/1000000000001/settings' -k  | python -m json.tool | grep name
...
        "name": "cfme-02",
...


# before the next api call, check the server name one more time (the name has not changed)
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | grep name
...
        "name": "cfme-02",
...

# update a different setting, check it first
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | grep company
...
        "company": "My Company",
...

# update the setting (the new setting is appropriately updated
curl -X PATCH -u 'admin:smartvm' -d "{\"server\":{\"company\":\"EXAMPLE\"}}" 'https://192.168.50.184/api/servers/1000000000001/settings' -k  | python -m json.tool | grep company
...
        "company": "EXAMPLE",
...

# check both settings (the last api call we made was kept, but the first one was not persisted)
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | egrep '(company|name)'
...
        "company": "EXAMPLE",
        "name": "EVM",
...

# reverse the behavior (check our name first)
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | grep name

...
        "name": "EVM",
...

# update the first setting
curl -X PATCH -u 'admin:smartvm' -d "{\"server\":{\"name\":\"cfme-02\"}}" 'https://192.168.50.184/api/servers/1000000000001/settings' -k  | python -m json.tool | grep name
...
        "name": "cfme-02",
...

# verify both settings (notice how the my company settings were reverted, but the server name settings were kept)
curl -X GET -u 'admin:smartvm' 'https://192.168.50.184/api/servers/1000000000001/settings' -k | python -m json.tool | egrep '(company|name)'
...
        "company": "My Company",
        "name": "cfme-02",
...


This indicates that the settings API is (just guessing) loading settings on default for each API call, and only updating the settings with the payload provided.  Because the settings are defaulted each time, only one API call for settings could potentially be persisted.




Version-Release number of selected component (if applicable):

cfme-5.9.2.4-1.el7cf.x86_64
cfme-appliance-5.9.2.4-1.el7cf.x86_64
cfme-appliance-common-5.9.2.4-1.el7cf.x86_64
cfme-appliance-tools-5.9.2.4-1.el7cf.x86_64
cfme-gemset-5.9.2.4-1.el7cf.x86_64
rh-ruby23-rubygem-redhat_access_cfme-2.0.2-2.el7cf.noarch


How reproducible:

100%


Steps to Reproduce:
1. See above for a sample of how to reproduce this problem.
2.
3.


Actual results:

Multiple API calls only persist the last call that was made.  Each previous API call reverts to the default settings.


Expected results:

Consumers of the API should be able to make multiple API calls to the CloudForms settings API without fear of previous settings being reverted, and without fear that their current API might be reverted by a future API call.


Additional info:

A workaround to this, albeit a not very good one, would be to pass in the payload for the updated settings each time the call is made.  This makes whomever is coding against the API's responsibility to put together the entire payload structure, and pass that structure in one call.  But again, if anyone would make a single call at a later point, it seems those settings are at risk to be reverted back to default, which is not ideal for something that perhaps might reside in production.