Bug 1476026 - Service Catalog issues repeated Deprovision requests against the broker, despite a 410 response
Service Catalog issues repeated Deprovision requests against the broker, desp...
Status: NEW
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.6.z
Assigned To: Paul Morie
DeShuai Ma
Depends On:
  Show dependency treegraph
Reported: 2017-07-27 17:02 EDT by Erik Nelson
Modified: 2017-07-31 09:54 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Erik Nelson 2017-07-27 17:02:51 EDT
Description of problem:
The service broker is receiving repeated deprovision (DELETE) requests despite reporting that the service instance is "gone" with a 410 response and a {} body, as outlined in the spec: https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#response-6

How reproducible:
Reproducible every time with OCP 3.6.0 catalog and broker.

Steps to Reproduce:
1. Provision a service
2. Deprovision
3. Observe ansible-service-broker logs and controller-manager logs. Catalog should not continue to request DELETES

Actual results:
* Initial deprovision comes in, we're seeing two of them almost on top of one another. Broker responds with correct 202, { "operation": "<operation_id>" }
* Wait for some time, the broker's pods have started to deprovision services.
* Additional DELETE request comes in, broker responds with a 410, {}.
* Broker continues to receive DELETE requests against the same service instance ID despite already having reported its gone.

Expected results:
Broker should stop receiving DELETE requests after responding with a 410, gone.

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