Bug 1502033 - Service catalog fails to propagate Service Plan updates to clusterServicePlan object
Summary: Service catalog fails to propagate Service Plan updates to clusterServicePlan...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.7.0
Assignee: Paul Morie
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-10-13 19:10 UTC by Dylan Murray
Modified: 2017-12-18 13:22 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-18 13:22:48 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:3464 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.7 bug fix and enhancement update 2017-12-18 18:22:05 UTC

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


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