Bug 1605136 - UI misbehaves when changing values to do with repo ref and context directory
Summary: UI misbehaves when changing values to do with repo ref and context directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Service Broker
Version: 3.9.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.1.0
Assignee: jkim
QA Contact: Zihan Tang
URL:
Whiteboard:
: 1618512 1666672 (view as bug list)
Depends On: 1668534
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-20 09:20 UTC by Ian Lawson
Modified: 2019-06-04 10:40 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2019-06-04 10:40:22 UTC
Target Upstream Version:


Attachments (Terms of Use)
Processed template request clears fields (116.83 KB, image/png)
2018-07-23 11:45 UTC, Samuel Padgett
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 None None None 2019-06-04 10:40:28 UTC

Description Ian Lawson 2018-07-20 09:20:39 UTC
Description of problem:

Choosing one of the standard JBoss EAP/JWS templates and then changing the git repo address, then removing (wiping) the git reference and context directory (i.e. setting the field to empty) does *not* alter the default fields. This means when the build starts it has not removed the git reference and context directory, causing an instant build (pull) fail. This is very misleading from a UI perspective.


Version-Release number of selected component (if applicable):

OCP 3.9.31


How reproducible:

Always


Steps to Reproduce:
1. Add to project
2. Select an example EAP template (i.e. 7.1 without https)
3. Change the git repo (i.e. https://github.com/utherp0/os-rest-comntainerview
4. Wipe the 'context directory' and 'git reference' input fields
5. Click Next to start the build

Actual results:

Build instantly fails due to the inherited 'context directory' and 'git reference' being added to the buildconfig even though the fields were wiped on the input page


Expected results:

Empty fields in the input page should result in no information for 'context directory' and 'git reference' being added to the buildconfig

Additional info:

Comment 1 Samuel Padgett 2018-07-23 11:44:49 UTC
Do you have service catalog and template service broker installed?

I'm not seeing this behavior through the normal template flow.

Comment 2 Samuel Padgett 2018-07-23 11:45:58 UTC
Created attachment 1469925 [details]
Processed template request clears fields

I also checked the build config that was created, and it didn't have the context dir or git ref set.

Comment 3 Samuel Padgett 2018-07-23 12:06:39 UTC
I was able to reproduce against template service broker. The parameters the UI creates is:

```json
{"APPLICATION_NAME":"eap-app","AUTO_DEPLOY_EXPLODED":"false","IMAGE_STREAM_NAMESPACE":"openshift","MAVEN_ARGS_APPEND":"-Dcom.redhat.xpaas.repo.jbossorg","MEMORY_LIMIT":"1Gi","SOURCE_REPOSITORY_URL":"https://github.com/jboss-developer/jboss-eap-quickstarts"}
```

Note that we cannot set these fields explicitly to "" because it breaks generated values. (Values are not generated when a parameter is explicitly set to "".) We had to remove these fields from the parameters JSON.

See discussion in: https://github.com/openshift/origin/issues/14445

And also the logic here:

https://github.com/openshift/origin-web-catalog/blob/e8edb4beebd5b82a4cf41b3ee7baec6e53240b7e/src/components/order-service/order-service.controller.ts#L442-L454

I don't believe there is a fix we can make only in the UI, so this needs to be addressed in the template service broker itself.

Comment 4 Ian Lawson 2018-07-23 12:20:11 UTC
Would it make sense from a UI perspective to default the parameters (webpage side) to 'master' and '/' (i.e. -p SOURCE_REPOSITORY_REF="master" -p CONTEXT_DIR="/")?

These would work by default.....

Comment 5 Samuel Padgett 2018-08-18 17:52:19 UTC
*** Bug 1618512 has been marked as a duplicate of this bug. ***

Comment 6 Veer Muchandi 2018-10-01 13:03:28 UTC
Is anyone fixing this issue whether on template service broker or in the UI? It keeps failing during our workshops and makes us look bad.

Comment 7 John Matthews 2018-10-04 14:01:55 UTC
Veer we have not worked this issue yet.

I'll align to 4.0.0 and we will investigate next sprint, at present I'm not sure what the proper fix should be.

Comment 9 jkim 2018-10-29 02:41:53 UTC
This bug requires a UI change.

Depends on 
https://github.com/openshift/console/pull/711

Comment 11 openshift-github-bot 2018-12-02 01:24:51 UTC
Commit pushed to master at https://github.com/openshift/origin

https://github.com/openshift/origin/commit/f049170804b05b5652425ab1a26645544407c867
Merge pull request #21371 from johnkim76/BZ1605136

Bug 1605136 - allow empty string values for non-generated parameters

Comment 12 Samuel Padgett 2019-01-16 14:59:42 UTC
*** Bug 1666672 has been marked as a duplicate of this bug. ***

Comment 15 Zihan Tang 2019-02-27 03:07:51 UTC
In v4.0, the UI API is different from v3.9.
In this API: api/kubernetes/api/v1/namespaces/.../secrets  the parameters can be successfully post.
step: 
1. select 'eap' template , click 'create instance'
2. Change the git repo to https://github.com/utherp0/os-rest-containerview
4. Wipe the 'context directory' and 'git reference' input fields, then create.
I catch the parameters are post and created successfully.

"{"ARTIFACT_DIR":"","GENERIC_WEBHOOK_SECRET":"","IMAGE_STREAM_NAMESPACE":"openshift","JGROUPS_CLUSTER_PASSWORD":"","SOURCE_REPOSITORY_REF":"","MAVEN_MIRROR_URL":"","MAVEN_ARGS_APPEND":"-Dcom.redhat.xpaas.repo.jbossorg","AUTO_DEPLOY_EXPLODED":"false","HOSTNAME_HTTP":"","GITHUB_WEBHOOK_SECRET":"","APPLICATION_NAME":"eap-app","MQ_CLUSTER_PASSWORD":"","MQ_QUEUES":"","CONTEXT_DIR":"","MEMORY_LIMIT":"1Gi","SOURCE_REPOSITORY_URL":"https://github.com/utherp0/os-rest-containerview","MQ_TOPICS":""}

VERIFIED
kubernetes v1.12.4+4dd65df23d
Cluster version is 4.0.0-0.nightly-2019-02-26-05433

Comment 18 errata-xmlrpc 2019-06-04 10:40:22 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-2019:0758


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