Description of problem: I have tried various combinations and structure of the credentials (auth_type and userid/password), but I was unable to create the provider with the token specified: curl -k -XPOST -d@- https://localhost/api/providers/ -u admin:smartvm; do sleep 1 done <<EOF { "name":"openshift-ansible-deployment_one-stack", "port":"8443", "hostname":"A.B.C.D", "zone_id":1, "type":"ManageIQ::Providers::Openshift::ContainerManager", "tenant_id":1, "credentials": [{ "auth_type": "bearer", "userid": "foo", "password": "..."} ] } Version-Release number of selected component (if applicable): API: "name":"API","description":"REST API","version":"2.1.0" EVM: master.20151104101111_14facbb How reproducible: always Steps to Reproduce: 1. Do what the description says Actual results: The provider is created fine, but the token in the WebGUI is empty and it seem not to be collecting the info. Expected results: The provider is created fine, and the token filed in WebGUI is not empty and it is collecting the info. Additional info:
Jaroslav, Could you clarify what is meant by the token's being empty in the WebGUI? Even better if you could provide a screenshot. Thanks!
(In reply to Tim Wade from comment #2) > Jaroslav, > > Could you clarify what is meant by the token's being empty in the WebGUI? > Even better if you could provide a screenshot. Thanks! Well there is nothing what you might not understand. It is simple. The token field is empty. There seem to be no way of fill it using REST. If you set the token trough web-gui and then later you check the provider, the token is non-empty, therefore I conclude it is not being set using REST.
Created attachment 1090159 [details] token filled
Created attachment 1090160 [details] token empty
Jaroslav, Thanks for the additional info. You mentioned you have tried various combinations. Have you tried providing the auth_key in the credentials? i.e. { "name":"openshift-ansible-deployment_one-stack", "port":"8443", "hostname":"A.B.C.D", "zone_id":1, "type":"ManageIQ::Providers::Openshift::ContainerManager", "tenant_id":1, "credentials": [ { "auth_type": "bearer", "userid": "foo", "password": "...", "auth_key": "-----BEGIN\sRSA\sPRIVATE\sKEY-----[...]" } ] }
(In reply to Tim Wade from comment #6) > Jaroslav, > > Thanks for the additional info. You mentioned you have tried various > combinations. Have you tried providing the auth_key in the credentials? > > i.e. > > > { > "name":"openshift-ansible-deployment_one-stack", > "port":"8443", > "hostname":"A.B.C.D", > "zone_id":1, > "type":"ManageIQ::Providers::Openshift::ContainerManager", > "tenant_id":1, > "credentials": [ > { > "auth_type": "bearer", > "userid": "foo", > "password": "...", > "auth_key": "-----BEGIN\sRSA\sPRIVATE\sKEY-----[...]" > } > ] > } curl -k -XPOST -d@- https://A.B.C.D/api/providers/ -u admin:smartvm; do sleep 1 done <<EOF { "name":"openshift-ansible-deployment_one-stack", "port":"8443", "hostname":"10.8.188.230", "zone_id":1, "type":"ManageIQ::Providers::Openshift::ContainerManager", "tenant_id":1, "credentials": [{ "auth_type": "bearer", "userid": "foo", "auth_key": "eyJhbG...NMZACgkm-jaGQ"} ] } EOF {"error":{"kind":"bad_request","message":"Could not create the new provider - Unsupported credential attributes auth_key specified, ManageIQ::Providers::Openshift::ContainerManager supports: userid, password","klass":"ApiController::BadRequestError"}}
Jaroslav, Thanks for trying that. I think I now see what's going on. I've created a PR for this here: https://github.com/ManageIQ/manageiq/pull/5364
*** Bug 1280257 has been marked as a duplicate of this bug. ***
curl -k -XPOST -d@- https://localhost/api/providers/ -u admin:smartvm <<EOF { "name":"openshift-ansible-deployment_one", "port":"8443", "hostname":"A.B.C.D", "zone_id":1, "type":"ManageIQ::Providers::Openshift::ContainerManager", "tenant_id":1, "credentials": [{ "auth_type": "bearer", "userid": "foo", "auth_key": "$auth" }]} EOF Worked
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/RHSA-2015:2551