Description of problem:
When update a serviceinstance without changing parameters such as only update plan, the web console will still post a request to create a new secret, the process is different with updating instance in backend.
Version-Release number of selected component (if applicable):
Web Console version : v3.9.19
Steps to Reproduce:
1. provision a postsql-apb in prod plan
2. update postsql-apb to dev plan from web console.
3. check http request in step 2.
step 3 ,
Not request to create a new secret , use the old secret to update serviceinstance.
The update parameters schema for the PostgresSQL (APB) is different from the create parameters schema. The update parameters schema has only a `postgresql_version` parameter. To avoid sending parameters that the broker might not accept for update, we create a new secret with just the `postgres_version` parameter value. You can see that the parameter secrets are in fact different if you look at the JSON parameters value for each.
This is working as intended.
the servivce-catalog and asb support updating serviceinstance include the following 2 function:
1. updating spec.clusterServicePlanExternalName and spec.updateRequests to update the plan, do not need to use a new secret file.
2. if only update to a new secret without plan , the asb will filter the parameter which is not changed. That is to say , if using a new secret file which contain the same parameters , it will actually not cause update in backend.
API(/apis/servicecatalog.k8s.io/v1beta1/namespaces/*/serviceinstances/*) might support same functions.
John , can you help confirm it ?
If it supports, the UI side can only update 'spec.clusterServicePlanExternalName' and 'spec.updateRequests' in the payload, so do not need to create a new secret.
If it is not ,
John , can you help confirm this is working as designed ?
From QE side, we concerned is that we have different processes while user update a serviceinstance from web console and backend at present.
Update from web console: will create a new secret, such as, rh-postgresql-apb9car7(there is a potential issue in here, the secret name is not readable, the original secret name is rh-mediawiki-apb-parametersz17l6), and POST API to trigger serviceinstance update.
Update from backend: user always update "plan" or "version" directly by oc cli, it will not create a new secret and trigger serviceinstance update directly.
They are different in our and customer side, we hope to confirm if it is by design or not.
I'm re-opening this bug only to make sure everything can be traced well, I will close this bug again while get clarification(if it's working as intended) from service catalog side. Thanks.
Let me start by saying I think there's a usability problem here. But the web console is doing the right thing by sending only update parameters.
The CLI process you explain is not really correct given the current behavior of service catalog. You're sending additional parameters that the broker says it can't accept when changing only the plan. The ASB has been changed specifically to workaround the problem and ignore these parameters. But other brokers might not. See
There is an upstream issue tracking this
The problem is that there are brokers other than ASB. Even though it might work with ASB, requests to other brokers can fail.
It is possible for the web console to instead update the secret in place. However, doing that has downsides in that you'll have lost all record of the original parameters sent.
We can investigate reusing the current secret.
*** Bug 1562327 has been marked as a duplicate of this bug. ***
Marking this low priority since it's working as intended and is not a regression. We should try to address it, though.
Removing the needsinfo as seems like it's no longer relevant.
PR opened: https://github.com/openshift/origin-web-catalog/pull/680
This bug does not apply to the new 4.1 console. We do not plan to address this in the 3.x console.