Bug 1543521

Summary: second async bind call returns incorrect response
Product: OpenShift Container Platform Reporter: Michael Hrivnak <mhrivnak>
Component: Service BrokerAssignee: Michael Hrivnak <mhrivnak>
Status: CLOSED ERRATA QA Contact: Jian Zhang <jiazha>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.9.0CC: aos-bugs, chezhang, dzager
Target Milestone: ---   
Target Release: 3.9.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
undefined
 Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-28 14:27:28 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Michael Hrivnak 2018-02-08 15:56:35 UTC 
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.
Comment 1 Michael Hrivnak 2018-02-08 22:48:03 UTC 
https://github.com/openshift/ansible-service-broker/pull/750
Comment 2 David Zager 2018-02-15 19:14:50 UTC 
http://pkgs.devel.redhat.com/cgit/rpms/ansible-service-broker/commit/?h=rhaos-3.9-asb-rhel-7&id=911ffad9a1788a86983c54a1f58b9c9c6f88dbf4
Comment 4 Jian Zhang 2018-02-22 03:41:53 UTC 
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.
Comment 7 errata-xmlrpc 2018-03-28 14:27:28 UTC 
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