Bug 1543521 - second async bind call returns incorrect response
Summary: second async bind call returns incorrect response
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker   
(Show other bugs)
Version: 3.9.0
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.9.0
Assignee: Michael Hrivnak
QA Contact: Jian Zhang
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-08 15:56 UTC by Michael Hrivnak
Modified: 2018-03-28 14:27 UTC (History)
3 users (show)

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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github openshift ansible-service-broker issues 670 None None None 2018-02-08 15:56 UTC
Red Hat Product Errata RHBA-2018:0489 None None None 2018-03-28 14:27 UTC

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 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


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