Bug 1475949 - Service Catalog does not poll on async deprovision
Summary: Service Catalog does not poll on async deprovision
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3.7.0
Assignee: Paul Morie
QA Contact: Zhang Cheng
URL:
Whiteboard:
Depends On:
Blocks: 1475251
TreeView+ depends on / blocked
 
Reported: 2017-07-27 15:31 UTC by Jesus M. Rodriguez
Modified: 2017-11-28 22:05 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-28 22:05:56 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1476012 unspecified CLOSED Release note needed for Service Catalog deprovision behavior 2020-10-14 00:28:05 UTC
Red Hat Product Errata RHSA-2017:3188 normal SHIPPED_LIVE Moderate: Red Hat OpenShift Container Platform 3.7 security, bug, and enhancement update 2017-11-29 02:34:54 UTC

Internal Links: 1476012

Description Jesus M. Rodriguez 2017-07-27 15:31:36 UTC
Description of problem:
When deprovisioning an instance in the service catalog. An async deprovision is sent to the service-broker but there are no subsequent calls to the last_operation.

Version-Release number of selected component (if applicable):


How reproducible:
1) create (provision) a service instance
2) delete (deprovision) a service instance
3) look at the controller-manager logs you will see the Deprovision call, but no polling calls.

Additional info:

Upstream bug:
https://github.com/kubernetes-incubator/service-catalog/issues/1066

Upstream patch:
https://github.com/kubernetes-incubator/service-catalog/pull/1067

Comment 1 Erik Nelson 2017-07-27 20:53:31 UTC
It's been determined that *eventually* the catalog will recognize the deprovision is async and start to poll. The catalog needs to be patched with the attached PR to force an immediate polling of last_operation.

Comment 2 Paul Morie 2017-08-23 17:36:13 UTC
This is fixed in the version of the catalog currently in origin.

Comment 5 Zhang Cheng 2017-10-24 02:39:28 UTC
Paul, Could you help to confirm? Thanks.

Comment 6 Zhang Cheng 2017-10-26 08:59:54 UTC
Verified with latest image: v3.7.0-0.178.0.0

Have below similar log in controller-manager while deprovisoning:
I1026 08:38:42.328380       1 controller_instance.go:1182] ServiceInstance "aaa/dh-rhscl-postgresql-apb-n4877": Polling last operation
I1026 08:38:42.339231       1 controller_instance.go:1315] ServiceInstance "aaa/dh-rhscl-postgresql-apb-n4877": Poll returned "in progress" : %!q(*string=<nil>)
I1026 08:38:42.339279       1 controller_instance.go:1414] ServiceInstance "aaa/dh-rhscl-postgresql-apb-n4877": Last operation not completed (still in progress)
I1026 08:38:43.079399       1 controller_instance.go:1077] ServiceInstance "aaa/dh-rhscl-postgresql-apb-n4877": Processing

Comment 9 errata-xmlrpc 2017-11-28 22:05:56 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/RHSA-2017:3188


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