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
@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?
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
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.
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.
Thanks Jian! Looks great.
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