Reported upstream: https://github.com/openshift/ansible-service-broker/issues/670 Description of problem: I made exactly the same async bind call twice in rapid succession. When the second call was made, the first operation was still running on the server. Per the proposed OSB API spec, the second call should return the same token as the first in the body and a response code of 202. Instead it returned the provision credentials and a 200. Version-Release number of selected component (if applicable): release-1.1 branch How reproducible: always Steps to Reproduce: 1. configure the broker to run APBs on bind/unbind and auto-escalate 2. make identical PUT requests to create a binding with accepts_complete=true in rapid succession Actual results: The second call returned the provision credentials and a 200. Expected results: Both calls should return a 202 and the token.
https://github.com/openshift/ansible-service-broker/pull/750
http://pkgs.devel.redhat.com/cgit/rpms/ansible-service-broker/commit/?h=rhaos-3.9-asb-rhel-7&id=911ffad9a1788a86983c54a1f58b9c9c6f88dbf4
The ASB version: 1.1.13 [root@host-172-16-120-90 ~]# docker run --rm --entrypoint=asbd brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/openshift3/ose-ansible-service-broker:v3.9 --version 1.1.13 Steps: 1, Enable the ASB async and auto-escalate, configure as below: broker: ... dev_broker: true launch_apb_on_bind: true auto_escalate: true 2, Provision an APB(for example, PostgreSQL) [root@host-172-16-120-90 ~]# oc get pods -n test2 NAME READY STATUS RESTARTS AGE postgresql-9.6-dev-1-zrtsl 1/1 Running 0 42m 3, Make identical PUT requests to create a binding with accepts_complete=true in rapid succession, there is a script for this, below: [jzhang@localhost ~]$ uuidgen 5f7266fc-2663-4db9-a408-9a8753196c84 [jzhang@localhost ~]$ cat manybinds.sh for i in 1 2 do echo "!!!Loop $i" ./bind.sh 5f7266fc-2663-4db9-a408-9a8753196c84 done [jzhang@localhost ~]$ cat bind.sh INSTANCE_ID="4d32ebf2-9843-46b0-9e17-2d2e44df1b65" #BINDING_ID=$(uuidgen) BINDING_ID=$1 PLAN_UUID="9783fc2e859f9179833a7dd003baa841" SERVICE_UUID="rh-postgresql-apb-2n286" IDENTITY=$(echo -n '{"groups":["system:authenticated:oauth","system:authenticated"],"scopes.authorization.openshift.io":["user:full"],"uid":"","username":"jiazha"}'|base64 -w 0) echo "binding ID: $BINDING_ID" req="{ \"plan_id\": \"$PLAN_UUID\", \"service_id\": \"$SERVICE_UUID\", \"context\": \"blog-project\", \"app_guid\":\"\", \"bind_resource\":{}, \"parameters\": {} }" curl \ -k -i \ -X PUT \ -H "Authorization: bearer $(oc whoami -t)" \ -H "Content-type: application/json" \ -H "Accept: application/json" \ -H "X-Broker-API-Originating-Identity: kubernetes $IDENTITY" \ -d "$req" \ "https://asb-1338-openshift-ansible-service-broker.apps.0222-f3r.qe.rhcloud.com/ansible-service-broker/v2/service_instances/$INSTANCE_ID/service_bindings/$BINDING_ID?accepts_incomplete=true" 4, Execute the above script. [jzhang@localhost ~]$ ./manybinds.sh !!!Loop 1 binding ID: 5f7266fc-2663-4db9-a408-9a8753196c84 HTTP/1.1 202 Accepted Content-Type: application/json Date: Thu, 22 Feb 2018 03:23:03 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=f703431a61ba1fb0714af05e9f45b12e; path=/; HttpOnly; Secure { "operation": "00dcabf0-e066-4da2-ad91-d9348264c6bf" } !!!Loop 2 binding ID: 5f7266fc-2663-4db9-a408-9a8753196c84 HTTP/1.1 202 Accepted Content-Type: application/json Date: Thu, 22 Feb 2018 03:23:05 GMT Content-Length: 58 Set-Cookie: 89a6d633054ded194d4e1360cdc1fbef=f703431a61ba1fb0714af05e9f45b12e; path=/; HttpOnly; Secure { "operation": "00dcabf0-e066-4da2-ad91-d9348264c6bf" } The second response is 202 and the job id as the same as the first one, so, LGTM.
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:0489