Bug 1375275 - oc process "FOO=a=b" error "invalid parameter assignment" if value contains the equal sign
Summary: oc process "FOO=a=b" error "invalid parameter assignment" if value contains t...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Ben Parees
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-12 15:12 UTC by Marek Schmidt
Modified: 2017-03-08 18:26 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Improper argument parsing rejected valid values. Consequence: Parameter values containing equal signs were incorrectly rejected. Fix: Change parsing to tolerate values containing equal signs. Result: Parameter values containing equal signs are tolerated.
Clone Of:
Environment:
Last Closed: 2016-09-27 09:47:28 UTC
Target Upstream Version:


Attachments (Terms of Use)
jboss-fuse-camel-amq-template.json (9.22 KB, text/plain)
2016-09-12 15:12 UTC, Marek Schmidt
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1933 normal SHIPPED_LIVE Red Hat OpenShift Container Platform 3.3 Release Advisory 2016-09-27 13:24:36 UTC

Description Marek Schmidt 2016-09-12 15:12:07 UTC
Created attachment 1200239 [details]
jboss-fuse-camel-amq-template.json

Description of problem:

Running 

oc process -f jboss-fuse-camel-amq-template.json "MAVEN_ARGS_APPEND=-Dfoo=bar -Dbar=foo"

causes an error

invalid parameter assignment in "s2i-jboss-fuse-camel-amq": "MAVEN_ARGS_APPEND=-Dfoo=bar -Dbar=foo"

The same command works correctly in previous version (OCP 3.2)

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

oc version
oc v3.3.0.29
kubernetes v1.3.0+52492b4
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://api.devel.xpaas:8443
openshift v3.3.0.29
kubernetes v1.3.0+52492b4


How reproducible:

Always

Steps to Reproduce:
1. Run 

oc process -f jboss-fuse-camel-amq-template.json "MAVEN_ARGS_APPEND=-Dfoo=bar -Dbar=foo"

on the attached template json file

Actual results:

invalid parameter assignment in "s2i-jboss-fuse-camel-amq": "MAVEN_ARGS_APPEND=-Dfoo=bar -Dbar=foo"

Expected results:

list of objects with a build config containing "name": "MAVEN_ARGS_APPEND",  "value": "-Dfoo=bar -Dbar=foo"

Additional info:

This used to work in OCP 3.2 

$ ./stable-oc version
stable-oc v3.2.1.13-1-gc2a90e1
kubernetes v1.2.0-36-g4a3f9c5


so this is a regression

Comment 2 Ben Parees 2016-09-12 18:42:29 UTC
fix: https://github.com/openshift/origin/pull/10880

Comment 3 Xingxing Xia 2016-09-13 07:47:06 UTC
Checked on devenv-rhel7_5003 (openshift v1.3.0-rc1+3cd9a1f). Fixed. Multi '='s work well. Wait for merge into OCP.

Comment 4 Brenton Leanhardt 2016-09-13 11:58:14 UTC
Can we discuss the severity of this bug?

Obviously some 'oc process' commands may be broken.  However, I would think as a workaround someone could grab the latest oc client from Origin.  This doesn't seem like a blocker unless a significant number of templates are going to be broken.

Also, I'm moving this back to ASSIGNED until we triage it for OCP.  This bug should have been moved ON_QA against Origin.

Comment 5 Marek Schmidt 2016-09-13 12:03:31 UTC
I would say this may affect xPaaS customers quite considerably, as any custom maven or java arguments have the form of "-Dfoo=bar"

Comment 6 Ben Parees 2016-09-13 12:06:11 UTC
@brenton i think you've summarized it accurately.  my main concern is the the use case that hit this bug seems likely to be a common one (jvm args are commonly going to include multple =s).

but yes, workarounds do exist.

Comment 7 Brenton Leanhardt 2016-09-13 12:12:03 UTC
It seems like we may need to perform a rebuild for another high severity bug.  Given this is low risk I would say please submit a PR against ose's enterprise-3.3 branch.

Comment 8 Ben Parees 2016-09-13 12:15:59 UTC
Already there:
https://github.com/openshift/ose/pull/364

Comment 10 Xingxing Xia 2016-09-14 02:28:22 UTC
(In reply to Brenton Leanhardt from comment #7)
> bug.  Given this is low risk I would say please submit a PR against ose's
> enterprise-3.3 branch.

From above discussion, the bug is low risk; H severity is because use case is common.

(In reply to Xingxing Xia from comment #3)
> Checked on devenv-rhel7_5003 (openshift v1.3.0-rc1+3cd9a1f). Fixed. Multi
> '='s work well. Wait for merge into OCP.

As said, wait for merge into new puddle.

Comment 11 Brenton Leanhardt 2016-09-14 12:23:55 UTC
We hope to have an official build for QE testing tomorrow.

Comment 12 Troy Dawson 2016-09-15 20:43:22 UTC
This has been merged into OCP and is in version v3.3.0.31.  This is planned on the GA release.  It is in images now and ready for testing.

Comment 13 Troy Dawson 2016-09-15 20:46:58 UTC
My bad, I didn't notice it was already on the Errata.
It's ready for QE now.

Comment 15 Marek Schmidt 2016-09-20 06:57:38 UTC
AFAIK this bug never affected any released version, so it doesn't need doc text?

Comment 16 Ben Parees 2016-09-20 07:51:08 UTC
The regression went in on may 2nd:
https://github.com/openshift/origin/pull/8049
was that included in 3.2 or 3.2.1?

Comment 18 errata-xmlrpc 2016-09-27 09:47:28 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-2016:1933


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