Description of problem: OpenShift is now requiring the Content-Type header on POST/PUT request, otherwise it fails on: "the body of the request was in an unknown format - accepted media types include: application/json, application/yaml" How reproducible: 100% Steps to Reproduce: 1. Run SmartState Analysis against OpenShift 3.2 Actual results: Request of instantiating the image-inspector pod is failing on "the body of the request was in an unknown format - accepted media types include: application/json, application/yaml" Expected results: The image-inspector pod should run as expected.
David, I saw this happening today on OpenShift Origin v1.1.3, is this present downstream as well? Is this issue going to be addressed on the OpenShift side (e.g. assuming json by default?), or should we actually fix it on our side? Also, if we go ahead and we fix this on our side... using Content-Type against older versions of OpenShift could create other issues?
Check to make sure you're not filling the `Content-Type` header. An empty `Content-Type` is defaulted to application/json. See this as an example: curl -k -v -XPOST -H "Content-Type: " -H "Authorization: Bearer <YOUR TOKEN>" https://localhost:8443/api/v1/namespaces/bar/pods -d'{ "apiVersion": "v1", "kind": "Pod", "metadata": { "name": "valid-pod" }, "spec": { "containers": [ { "name": "kubernetes-serve-hostname", "image": "gcr.io/google_containers/serve_hostname" } ] } }' -v * Trying ::1... * connect to ::1 port 8443 failed: Connection refused * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8443 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * skipping SSL peer certificate verification * NSS: client certificate not found (nickname not specified) * ALPN, server accepted to use http/1.1 * SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 * Server certificate: * subject: CN=10.13.137.230 * start date: Mar 03 16:18:32 2016 GMT * expire date: Mar 03 16:18:33 2018 GMT * common name: 10.13.137.230 * issuer: CN=openshift-signer@1457021911 > POST /api/v1/namespaces/bar/pods HTTP/1.1 > Host: localhost:8443 > User-Agent: curl/7.43.0 > Accept: */* > Authorization: Bearer vnD93NMo3rtWE4wMmAE4Cm9H2nUzjS9kJkQ1yVFTG8U > Content-Length: 249 > * upload completely sent off: 249 out of 249 bytes < HTTP/1.1 201 Created < Cache-Control: no-store < Content-Type: application/json < Date: Mon, 07 Mar 2016 18:11:29 GMT < Content-Length: 1789 <
It seems that the RestClient gem secretly adds a wrong Content-Type.
David it seems that the easiest fix for us is to set the Content-Type to application/json, do you see any compatibility issue with prior versions of OpenShift (most notably 3.1).
No. That should be fully compatible. Our web-console does it as a for instance.
https://github.com/ManageIQ/manageiq/pull/7153
New commit detected on cfme/5.5.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=92f363cac841ed3c1ba37544ed37a8ac9eeecf62 commit 92f363cac841ed3c1ba37544ed37a8ac9eeecf62 Merge: fc63a7c a1a0cff Author: Greg Blomquist <gblomqui> AuthorDate: Fri Mar 11 09:28:59 2016 -0500 Commit: Greg Blomquist <gblomqui> CommitDate: Fri Mar 11 09:28:59 2016 -0500 Merge branch 'bump_kubeclient_version_55z' into '5.5.z' Gemfile: bumping kubeclient to 0.8.1 Conflicts: gems/pending/Gemfile NOT a clean cherry-pick https://github.com/ManageIQ/manageiq/pull/7153 https://bugzilla.redhat.com/show_bug.cgi?id=1315436 See merge request !843 gems/pending/Gemfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Verified on Version 5.5.3.2. Image inspector pod runs successfully on OSE 3.2.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2016:0616