Bug 1564979 - Shouldn't create a new secret if haven't changed parameters when update serviceinstance
Summary: Shouldn't create a new secret if haven't changed parameters when update servi...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 3.11.0
Assignee: bpeterse
QA Contact: Zihan Tang
URL:
Whiteboard:
: 1562327 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-09 05:56 UTC by Zihan Tang
Modified: 2019-06-04 20:36 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-04 20:36:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Zihan Tang 2018-04-09 05:56:34 UTC
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

How reproducible:
always

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.

Actual results:
step 3 , 
Request URL:https://host-8-241-107.host.centralci.eng.rdu2.redhat.com:8443/api/v1/namespaces/post1/secrets
Request Method:POST
Request Payload:
{
  "apiVersion": "v1",
  "kind": "Secret",
  "metadata": {
    "name": "rh-postgresql-apb9car7",
    "ownerReferences": [
      {
        "apiVersion": "servicecatalog.k8s.io/v1beta1",
        "kind": "ServiceInstance",
        "name": "rh-postgresql-apb-zch6j",
        "uid": "359aecd4-3b9c-11e8-a9f9-0a580a810006",
        "controller": false,
        "blockOwnerDeletion": false
      }
    ]
  },
  "type": "Opaque",
  "stringData": {
    "parameters": "{\"postgresql_version\":\"9.6\"}"
  }
}

Expected results:
Not request to create a new secret , use the old secret to update serviceinstance.

Additional info:

Comment 1 Samuel Padgett 2018-04-09 18:27:19 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.

Comment 2 Zihan Tang 2018-04-10 02:29:05 UTC
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 ?

Comment 3 Zhang Cheng 2018-04-10 03:08:21 UTC
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.

Comment 4 Zhang Cheng 2018-04-10 03:14:52 UTC
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.

Comment 5 Samuel Padgett 2018-04-10 03:53:49 UTC
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.

Comment 6 Samuel Padgett 2018-04-10 15:19:29 UTC
We can investigate reusing the current secret.

Comment 7 Jesus M. Rodriguez 2018-04-25 13:07:19 UTC
*** Bug 1562327 has been marked as a duplicate of this bug. ***

Comment 8 Samuel Padgett 2018-04-30 14:30:36 UTC
Marking this low priority since it's working as intended and is not a regression. We should try to address it, though.

Comment 9 John Matthews 2018-04-30 14:39:37 UTC
Removing the needsinfo as seems like it's no longer relevant.

Comment 10 bpeterse 2018-05-16 17:53:49 UTC
PR opened: https://github.com/openshift/origin-web-catalog/pull/680

Comment 11 Samuel Padgett 2019-06-04 20:36:36 UTC
This bug does not apply to the new 4.1 console. We do not plan to address this in the 3.x console.


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