Reported upstream: https://github.com/openshift/ansible-service-broker/issues/708 Description of problem: I initiated an async unbind and then called the last_operation endpoint with the given token. The response code was 410, and the body was "null". The proposed async bind/unbind specification says that the correct body for a 410 response is an empty json object: "{}". https://github.com/openservicebrokerapi/servicebroker/pull/334/files#diff-958e7270f96f5407d7d980f500805b1bR787 Version-Release number of selected component (if applicable): 1.1 release branch How reproducible: always Steps to Reproduce: 1. Configure the broker to run apbs on bind and unbind, and to auto-escalate. 2. Initiate an async unbind. 3. Make a request to the bind/unbind last_operation endpoint with the token proved in step 2. Actual results: body was null Expected results: body should be an empty json object
https://github.com/openshift/ansible-service-broker/pull/744
Michael, I saw the above PR was merged into the "release-1.1" branch. I did not know which image I should use to test it. Could you help to merge it into the "master" branch?
Verify failed. The ASB version: 1.1.15 [root@host-172-16-120-94 ~]# docker run --rm --entrypoint=asbd registry.reg-aws.openshift.com:443/openshift3/ose-ansible-service-broker:v3.9.1 --version 1.1.15 Test Steps: 1, Configure the broker to run apbs on bind and unbind, and to auto-escalate. registry: - type: dockerhub name: dh url: registry.hub.docker.com org: mhrivnak tag: latest white_list: [.*-apb$] ... broker: ... launch_apb_on_bind: true auto_escalate: true 2, Provision an APB which support async bind/unbind, for example, PostgreSQL, the corresponding registry as the above shows. 3, Create an async bind. Like below: [root@localhost jzhang]# ./bind.sh binding ID: 807d316c-3e7e-4fe4-9a04-b338895d2656 HTTP/1.1 202 Accepted Content-Type: application/json Date: Thu, 01 Mar 2018 05:48:02 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=300c42257001835d2d3504e0780f4d66; path=/; HttpOnly; Secure { "operation": "1c40aa9b-763b-46f5-abe7-04ba6ef1f2e3" } [root@localhost jzhang]# ./last_operation.sh 1c40aa9b-763b-46f5-abe7-04ba6ef1f2e3 { "state": "succeeded" } 4, Run the unbind. [root@localhost jzhang]# ./unbind.sh 807d316c-3e7e-4fe4-9a04-b338895d2656 HTTP/1.1 202 Accepted Content-Type: application/json Date: Thu, 01 Mar 2018 05:49:14 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=300c42257001835d2d3504e0780f4d66; path=/; HttpOnly; Secure { "operation": "2d54f71a-f0ab-4a26-a4dc-488da18f0820" } [root@localhost jzhang]# ./last_operation.sh 2d54f71a-f0ab-4a26-a4dc-488da18f0820 { "state": "succeeded" } 5, Run the unbind again. Here still return the "null" body, not an empty JSON object. [root@localhost jzhang]# ./unbind.sh 807d316c-3e7e-4fe4-9a04-b338895d2656 HTTP/1.1 410 Gone Content-Type: application/json Date: Thu, 01 Mar 2018 05:52:05 GMT Content-Length: 5 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=300c42257001835d2d3504e0780f4d66; path=/; HttpOnly; Secure Cache-control: private null The ASB logs: [2018-03-01T05:51:55.228Z] [DEBUG] - service_id: dh-postgresql-apb-jktdq [2018-03-01T05:51:55.228Z] [DEBUG] - plan_id: 7f4a5e35e4af2beb70076e72fab0b7ff [2018-03-01T05:51:55.228Z] [DEBUG] - operation: 2d54f71a-f0ab-4a26-a4dc-488da18f0820 [2018-03-01T05:51:55.23Z] [DEBUG] - state: succeeded 10.129.0.1 - - [01/Mar/2018:05:51:55 +0000] "GET /ansible-service-broker/v2/service_instances/c4c25934-8433-4e7e-bb31-f75d657dc8b5/last_operation?operation=2d54f71a-f0ab-4a26-a4dc-488da18f0820&service_id=dh-postgresql-apb-jktdq&plan_id=7f4a5e35e4af2beb70076e72fab0b7ff HTTP/1.1" 200 27 10.129.0.1 - - [01/Mar/2018:05:52:05 +0000] "DELETE /ansible-service-broker/v2/service_instances/c4c25934-8433-4e7e-bb31-f75d657dc8b5/service_bindings/807d316c-3e7e-4fe4-9a04-b338895d2656?accepts_incomplete=true&plan_id=7f4a5e35e4af2beb70076e72fab0b7ff HTTP/1.1" 410 5
This bug report and fix only changed the behavior of the last_operation endpoint. Specifically, you should see that a 410 response from the last_operation endpoint now has a body that complies with the spec. You discovered here that there is an additional and similar bug when the unbind endpoint gives a 410 response. We should address that separately. This bug fix made no changes to the unbind endpoint. And FWIW, discussion in the OSB API group sounds like they are going to drop the requirement that a 410 response have a body that's an empty JSON document. So I don't think it's worth spending time fixing the unbind endpoint's behavior right now.
Michael, Thanks for your clarifying. I create a script called "curl_last_operation.sh" to request the last_operation endpoint, and it works as expected. Details as below: [root@localhost jzhang]# cat curl_last_operation.sh BINDING_ID=$1 INSTANCE_ID="a88b73f0-2dd5-4478-92a1-44fcf30514ee" IDENTITY=$(echo -n '{"groups":["system:authenticated:oauth","system:authenticated"],"scopes.authorization.openshift.io":["user:full"],"uid":"","username":"jiazha"}'|base64 -w 0) curl \ -k -i \ -X GET \ -H "Authorization: bearer $(oc whoami -t)" \ -H "Content-type: application/json" \ -H "Accept: application/json" \ -H "X-Broker-API-Originating-Identity: kubernetes $IDENTITY" \ "https://asb-1338-openshift-ansible-service-broker.apps.0305-f77.qe.rhcloud.com/ansible-service-broker/v2/service_instances/$INSTANCE_ID/service_bindings/$BINDING_ID/last_operation" [root@localhost jzhang]# ./bind.sh binding ID: 64d624e7-6a54-4615-bbaa-5a30f20d15f8 HTTP/1.1 202 Accepted Content-Type: application/json Date: Mon, 05 Mar 2018 06:24:44 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=12f4d09fbe4fcbeddc38b620ad8fd853; path=/; HttpOnly; Secure { "operation": "dc913835-48d1-40a5-9561-f1f1f17b3cbe" } [root@localhost jzhang]# ./curl_last_operation.sh 64d624e7-6a54-4615-bbaa-5a30f20d15f8 HTTP/1.1 400 Bad Request Content-Type: application/json Date: Mon, 05 Mar 2018 06:25:00 GMT Content-Length: 125 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=12f4d09fbe4fcbeddc38b620ad8fd853; path=/; HttpOnly; Secure { "description": "operation not supplied for a last_operation with instance_uuid [a88b73f0-2dd5-4478-92a1-44fcf30514ee]" } [root@localhost jzhang]# ./unbind.sh 64d624e7-6a54-4615-bbaa-5a30f20d15f8 HTTP/1.1 202 Accepted Content-Type: application/json Date: Mon, 05 Mar 2018 06:25:09 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=12f4d09fbe4fcbeddc38b620ad8fd853; path=/; HttpOnly; Secure { "operation": "7ea6c2e8-d076-4664-a684-107557bce458" } [root@localhost jzhang]# ./curl_last_operation.sh 64d624e7-6a54-4615-bbaa-5a30f20d15f8 HTTP/1.1 410 Gone Content-Type: application/json Date: Mon, 05 Mar 2018 06:25:15 GMT Content-Length: 3 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=12f4d09fbe4fcbeddc38b620ad8fd853; path=/; HttpOnly; Secure Cache-control: private {} The response status code and body as we expected, LGTM. The ASB version: 1.1.15
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-2018:3748