Bug 1502033

Summary:	Service catalog fails to propagate Service Plan updates to clusterServicePlan object
Product:	OpenShift Container Platform	Reporter:	Dylan Murray <dymurray>
Component:	Service Broker	Assignee:	Paul Morie <pmorie>
Status:	CLOSED ERRATA	QA Contact:	Jian Zhang <jiazha>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.7.0	CC:	aos-bugs, chezhang, dymurray, fabian, pmorie, xtian
Target Milestone:	---
Target Release:	3.7.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-18 13:22:48 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 Dylan Murray 2017-10-13 19:10:51 UTC

Description of problem:
After deploying the broker we create a secret which provides some parameter fields and updates to the APBs service plan. This update does not get propagated to the clusterserviceplan resource.

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

How reproducible:
100%

Steps to Reproduce:
1. Deploy service broker
2. Create secret for relevant parameters to update serviceplan
3. Check output of `oc get clusterserviceplans` to see the change not propagated.

Actual results:
clusterserviceplan does not have same data as serviceplan in broker

Expected results:
clusterserviceplan has same data as serviceplan

Additional info:
Additional logs are available in:
https://github.com/kubernetes-incubator/service-catalog/issues/1388

Comment 1 Paul Morie 2017-10-16 13:18:26 UTC

@dymurray - I think we might have a mismatch here.  I'm not sure what creating a secret has to do with the parameter payload returned by the Broker - can you elaborate?

Comment 2 Fabian von Feilitzsch 2017-10-16 13:27:30 UTC

This is just a behavior of the service broker, you can associate secrets with the broker to provide parameters (like AWS credentials/cluster level config for APBs). Any parameters provided in this manner won't be sent to the catalog. 

The secret isn't really related to the problem here though, it's just the easiest way to reproduce by changing the service plan definitions. Any change to the parameters in a service plan should have the same issue

Comment 3 Paul Morie 2017-10-17 19:36:09 UTC

I talked to Dylan offline and we sorted out what the issue is.  There is indeed a bug; this is fixed in https://github.com/openshift/origin/pull/16908; will move to MODIFIED.

Comment 6 Dylan Murray 2017-11-06 14:03:27 UTC

Qixuan,

"Update" a serviceplan in this instance means changing the actual definition of that serviceplan. You pasted the plan for the postgresql 'dev' plan. If the parameter list were to change from the ansible service broker that change was not being propagated to the service catalog.

To test this you could use our apb tooling to reproduce our use case (https://github.com/ansibleplaybookbundle/ansible-playbook-bundle) by changing the plan metadata and using `apb push` to update the plan from the broker and see if that change is propagated to the service catalog. This bug is hard to reproduce as it only appeared in our Amazon environment where we were doing some logic broker side to change the plan metadata dependent upon which secrets are created.

The important thing to test is that removing or adding parameters to the APB plan effectively shows up in the service catalog after it does a catalog request against the broker.

Comment 9 Dylan Murray 2017-11-08 13:38:09 UTC

Thanks Jian! Looks great.

Comment 12 errata-xmlrpc 2017-12-18 13:22:48 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-2017:3464