Created from redmine issue http://projects.theforeman.org/issues/10424

Upstream bug assigned to tomckay

Needed for hammer-cli-csv (SAM-1.4 to SAM-6.1 migration)

Moving to POST since upstream bug http://projects.theforeman.org/issues/10424 has been closed
-------------
Thomas McKay
Applied in changeset commit:katello|566f4a13c54802e4de032deeb9b4eb0de5dea233.

hi

please provide verification steps

thanks

To verify: Call the api via apipie bindings to update a content host. Prior to this fix the 'facts' param was required (as defined in apipie). This fix removes that requirement.

Tested against a Satellite 6.1.0 system running on RHEL 7.1.

    >>> from nailgun.entities import System
    >>> from nailgun import client
    >>> from nailgun.config import ServerConfig
    >>> cfg = ServerConfig.get()
    >>> path = System(cfg, id='8485c939-5c4d-4172-8131-e9e375e1c21b').path()
    >>> print(path)
    https://…/katello/api/v2/systems/8485c939-5c4d-4172-8131-e9e375e1c21b
    >>> response = client.put(path, **cfg.get_client_kwargs())
    WARNING:nailgun.client:Received HTTP 400 response: {"displayMessage":"Missing values for system.","errors":["key not found: system"]}
    >>> response = client.put(path, {}, **cfg.get_client_kwargs())
    WARNING:nailgun.client:Received HTTP 400 response: {"displayMessage":"Missing values for system.","errors":["key not found: system"]}
    >>> response = client.put(path, {'facts': {}}, **cfg.get_client_kwargs())
    >>> response.status_code
    200

Created attachment 1028937 [details]
Output of foreman-debug from the Satellite 6.1 RHEL 7.1 system used for testing.

I do not believe that error has to do with my changes, does it? I simply didn't require the facts params. Having to pass nested system params is an entirely different issue.

#c0 states that the JSON payload should not require a "facts" key when issuing a PUT request. I tested a server and discovered that:

* A PUT request fails when I do not provide "facts" in the JSON payload.
* A PUT request succeeds when I do provide "facts" in the JSON payload.

There in no other difference between the second and third request. Therefore, I conclude that the server still does require a "facts" key when issuing a PUT request and that the bug has not been fixed. The error message which mentions a "system" key is a totally different issue.

New API upstream (/systems changed to /hosts)