Unable to update resource using REST API PATCH, returns 415 Unsupported Media Type

[ghost]

Executing the following REST API call results in a 415, despite using a supposedly supported content type. Executing the same call using a known unsupported media type (such as text/plain) returns a expected 406 with list of valid content types that still result in a 415:

PATCH /oapi/v1/namespaces/myNamespace/deploymentconfigs/myDeploy Content-Type: application/json Accept: application/json Body:

{
  "spec": {
    "template": {
      "spec": {
        "containers": [
          {
            "image": "my.internalregistry.com/myImage@sha256:ced334154462d47c2e744f5cd3ec39a030ad2430a2dd78d7c5df8e31587ef258"
          }
        ]
      }
    }
  }
}

PATCH /oapi/v1/namespaces/myNamespace/deploymentconfigs/myDeploy Content-Type: text/plain Accept: text/plain Body "some junk that should return an error"

Response:

{
    "metadata": {},
    "status": "Failure",
    "message": "only the following media types are accepted: application/json, application/yaml, application/vnd.kubernetes.protobuf",
    "reason": "NotAcceptable",
    "code": 406
}

Version

openshift v3.6.173.0.21
kubernetes v1.6.1+5115d708d7

Steps To Reproduce

1. Execute REST API PATCH to partially update an existing resource such as https://docs.openshift.com/container-platform/3.6/rest_api/openshift_v1.html#partially-update-the-specified-deploymentconfig
2. Use a valid requestbody and content-type/accept headers of application/json.

Current Result

Response 415 Body

{
    "kind": "Status",
    "apiVersion": "v1",
    "metadata": {},
    "status": "Failure",
    "message": "the server responded with the status code 415 but did not return more information",
    "details": {},
    "code": 415
}

Expected Result

PATCH request returns 2xx response code and the resource is patched with the changed data.

[ghost]

As an aside, I did the "same" change using oc patch on the CLI. It was updated successfully.

$ oc patch dc my-app -p '{"spec":{"template":{"spec":{"containers":[{"name":"my-app","image":"myregistry.example.com/my-app@sha256:ea3aea0fdb9711d9b207b0c549fd1156bb
ae91ea1a5da75881316e514be6b1d4"}]}}}}'
"my-app" patched

[ghost]

After further investigation and a glance through RFC 6902, it looks like it was a request body schema that was the problem. Seems like a) it needs to be a json array and b) needs to include the "op", "path" and "value" keys following the RFC spec.

Here's a working request to patch a buildconfig:

PATCH /oapi/v1/namespaces/myProject/buildconfigs/myBuild Content-Type application/json-patch+json Accept application/json Body

[
    {
        "op": "replace",
        "path": "/spec/output/to/name",
        "value": "myregistry.example.com/myapp:latest-1"
    }
]

Could we add this in the OpenShift REST API documentation somewhere? GET, POST, PUT and DELETE should be straight-forward for most users as is. However, the PATCH is less straight forward in the docs (see https://docs.openshift.com/container-platform/3.5/rest_api/openshift_v1.html#unversioned-patch) and does not really give any clue as to how to properly format the request.

[mfojtik]

/assign @liggitt

[chrissound]

It would be immensely helpful to mention this bug/requirement in the Kubernetes API reference.

sorry... Wrong project

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten /remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen. Mark the issue as fresh by commenting /remove-lifecycle rotten. Exclude this issue from closing again by commenting /lifecycle frozen.

/close