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
Seems related to https://github.com/openshift/origin/commit/6eaf7a2690b72c352b417c62209911e462b96b9c
fix: https://github.com/openshift/origin/pull/10880
Checked on devenv-rhel7_5003 (openshift v1.3.0-rc1+3cd9a1f). Fixed. Multi '='s work well. Wait for merge into OCP.
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.
I would say this may affect xPaaS customers quite considerably, as any custom maven or java arguments have the form of "-Dfoo=bar"
@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.
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.
Already there: https://github.com/openshift/ose/pull/364
(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.
We hope to have an official build for QE testing tomorrow.
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.
My bad, I didn't notice it was already on the Errata. It's ready for QE now.
AFAIK this bug never affected any released version, so it doesn't need doc text?
The regression went in on may 2nd: https://github.com/openshift/origin/pull/8049 was that included in 3.2 or 3.2.1?
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