Bug 1280216

Summary: Setting env vars via Web UI not visible in the assemble phase of STI build (https://github.com/openshift/origin/issues/5817)
Product: OpenShift Container Platform Reporter: Miheer Salunke <misalunk>
Component: Management ConsoleAssignee: Jessica Forrester <jforrest>
Status: CLOSED ERRATA QA Contact: Yadan Pei <yapei>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: aos-bugs, bleanhar, bparees, jialiu, jokerman, mmccomas, wsun, xtian
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-26 19:17:19 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:
Attachments:
Description Flags
env vars via ui none

Description Miheer Salunke 2015-11-11 08:50:04 UTC 
Created attachment 1092615 [details]
env vars via ui

Description of problem:
This is to keep a track of https://github.com/openshift/origin/issues/5817

We still have case with variables not visible in Assemble phase. This is only occurs when BuildConfig is generated by Openshift in STI.
"ENV set in GUI not visible inside STI assemble phase
1. Set ENV variables in GUI
2. Try to use variables in assemble script - fails
3. Set via .sti/environment files - success"


- Attached example is from GUI, when you try to do Source-to-image build and you have to provide configurations and values for the deployment. 

If we creating custom templates/buildConfig we defining what environment variables we want to see. This is fine, but we want user to enter those via GUI and not from pre-defines list. Currently if we use templates - we have to define list of variables (hardcode), if we use STI build method and BuildConfig is generated by Openshift - these variables are visible only in run phase of STI, but not assemble. 

1. Templates would work for us IF templates would have capability to have environment variables not hardcoded, but capability to add them as we have in STI build (see attachment), but all values in templates have to be hardcoded, and we want this to be more flexible. In example user have to provide env variables for 5 data-sources. This means 5datsources x 5 config liens each = 25 parameters in template. So if we start counting MQ queues, and different other technologies we end up with infinity matrix of possible hardcoded templates.
 
2. We need to be able to produce environment variables inside one phase and see those in other. In example user set variable OPENSHIFT_VERSION_JDK=default_7

And in assemble phase i read this value and set JAVA_HOME,JRE_HOME _RUNJAVA to particular java7 default locations. So i would abstract user from resource management. This applies to database, drivers, other resources versions.  Currently there is no possibility to create variables visible for all build inside assemble and get them in run.

A github issue has been opened for this: https://github.com/openshift/origin/issues/5817 so this may be more understandable.


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

How reproducible:
Always

Steps to Reproduce:
1.
2.
3.

Actual results:

GUI generated BuildConfig Environment variables not visible in Assemble

Expected results:

GUI generated BuildConfig Environment variables shall be visible in Assemble

Additional info:
Comment 1 Ben Parees 2015-11-11 14:02:31 UTC 
There is no option to provide BuildConfig env variables via the webconsole when defining a new build.  The GUI allows you to supply DeploymentConfig env variables.

So this is not a bug.  If you want the ability to define env variables via the GUI flow, this should be converted to an RFE.
Comment 2 Jessica Forrester 2015-11-16 13:58:19 UTC 
Fixed in https://github.com/openshift/origin/pull/5893

you can independently specify build env vars and deployment env vars in the console during create.  The one thing to note is that build env vars are also available at runtime due to underlying system behavior.
Comment 3 Yadan Pei 2015-11-17 07:07:24 UTC 
Verified on devenv-rhel7_2717


Lines in my .sti/bin/assemble scripts:
echo "---> Displaying ENV vars"
echo $(env) 

ImageStream:
nodejs:0.10

1) On web console, create application with imageStream and sourceCode
2) On the creation page, set ENV vars in Build Configuration and Deployment Configuration
Environment Variables in Build Configuration are:
Name: TestBCOne   Value:value1
Name: TestBCTwo   Value:value2

Environment Variables in Deployment Configuration are:
Name: TestDCOne   Value:dcvalue1
Name: TestDCTwo   Value:dcvalue2
3) Create application
4) Check Build page
Environment Variables set in creation step are displayed in build page
5) Check Logs tab of Build page
Already on 'master'
---> Displaying ENV vars
MANPATH=/opt/rh/v8314/root/usr/share/man:/opt/rh/nodejs010/root/usr/share/man: ......TestBCTwo=value2 X_SCLS=v8314 nodejs010 ....TestBCOne=value1
---> Installing application source
---> Building your Node application from source
E1117 05:50:12.979093       1 util.go:85] npm info it worked if it ends with ok
.........
6) Check ENV vars in bc
# oc get bc -o yaml
    source:
      git:
        ref: master
        uri: https://github.com/yapei/nodejs-ex.git
      type: Git
    strategy:
      sourceStrategy:
        env:
        - name: TestBCOne
          value: value1
        - name: TestBCTwo
          value: value2
        from:
          kind: ImageStreamTag
          name: nodejs:0.10
          namespace: yapei-test
7) Check ENV vars in container
# oc rsh nodejs-ex-1-0qgk7
bash-4.2$ env | grep Test
TestDCOne=dcvalue1
TestBCTwo=value2
TestBCOne=value1
TestDCTwo=dcvalue2
bash-4.2$ 

Environment Variables defined on web console can be available in assemble phase of STI build, it works well
Comment 4 Yadan Pei 2015-11-17 07:08:28 UTC 
Will verify on Openshift Enterprise and Atomic Enterprise once merged on them
Comment 5 Yadan Pei 2015-11-18 05:58:51 UTC 
Will check again once fix merged on OSE, change to "MODIFIED"
Comment 8 Yadan Pei 2015-12-23 00:54:19 UTC 
Checked on 3.1.1.0

openshift v3.1.1.0
kubernetes v1.1.0-origin-1107-g4c8e6f4
etcd 2.1.2

This fix had been merged
Comment 10 errata-xmlrpc 2016-01-26 19:17:19 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/RHSA-2016:0070