Bug 1315436 - SmartState Analysis is Broken on OpenShift 3.2
SmartState Analysis is Broken on OpenShift 3.2
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers (Show other bugs)
Unspecified Unspecified
high Severity high
: GA
: 5.5.3
Assigned To: Erez Freiberger
Einat Pacifici
: ZStream
Depends On:
Blocks: 1317517
  Show dependency treegraph
Reported: 2016-03-07 12:49 EST by Federico Simoncelli
Modified: 2016-04-13 14:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1317517 (view as bug list)
Last Closed: 2016-04-13 14:45:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Federico Simoncelli 2016-03-07 12:49:37 EST
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:

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.
Comment 1 Federico Simoncelli 2016-03-07 12:53:00 EST
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?
Comment 2 David Eads 2016-03-07 13:13:28 EST
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
* Connected to localhost ( 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=
* 	start date: Mar 03 16:18:32 2016 GMT
* 	expire date: Mar 03 16:18:33 2018 GMT
* 	common name:
* 	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
Comment 3 Federico Simoncelli 2016-03-07 16:00:02 EST
It seems that the RestClient gem secretly adds a wrong Content-Type.
Comment 4 Federico Simoncelli 2016-03-07 16:03:06 EST
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).
Comment 5 David Eads 2016-03-07 16:04:16 EST
No.  That should be fully compatible.  Our web-console does it as a for instance.
Comment 6 Erez Freiberger 2016-03-08 11:29:54 EST
Comment 8 CFME Bot 2016-03-11 09:59:16 EST
New commit detected on cfme/5.5.z:

commit 92f363cac841ed3c1ba37544ed37a8ac9eeecf62
Merge: fc63a7c a1a0cff
Author:     Greg Blomquist <gblomqui@redhat.com>
AuthorDate: Fri Mar 11 09:28:59 2016 -0500
Commit:     Greg Blomquist <gblomqui@redhat.com>
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
    NOT a clean cherry-pick
    See merge request !843

 gems/pending/Gemfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 10 Einat Pacifici 2016-03-23 07:34:33 EDT
Verified on Version
Image inspector pod runs successfully on OSE 3.2.
Comment 12 errata-xmlrpc 2016-04-13 14:45:56 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.