Bug 1564979
Summary: | Shouldn't create a new secret if haven't changed parameters when update serviceinstance | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Zihan Tang <zitang> |
Component: | Management Console | Assignee: | bpeterse |
Status: | CLOSED WONTFIX | QA Contact: | Zihan Tang <zitang> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 3.9.0 | CC: | aos-bugs, chezhang, hasha, jiazha, jmatthew, jokerman, mmccomas, pmorie, spadgett, yapei |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | 3.11.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: | 2019-06-04 20:36:36 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
Zihan Tang
2018-04-09 05:56:34 UTC
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. Samuel, 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 https://github.com/openshift/origin-web-console/issues/2349 There is an upstream issue tracking this https://github.com/kubernetes-incubator/service-catalog/issues/1488 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. This bug does not apply to the new 4.1 console. We do not plan to address this in the 3.x console. |