Add configuration option for setting http(s) proxy in Dockerfile

With the review https://review.openstack.org/#/c/215541/ that has merged, I believe this blueprint has been implemented. I will leave it in 'Good Progress' until 8/29 at which point if no one has commented here I will mark it implemented. -- SamYaple

I think templating is a great way to solve this problem, so making it a dependency of the template blueprint. If someone signs up to do the work we can merge in liberty-3, else I'll push to the M cycle. -sdake

- This issue can be solved far easier once we implement templating in L3. These options can be used by those requiring a proxy while not affecting those who do not need it.

- suspect this will be a continuing problem. Setting priority and setting
- for liberty, but leaving in discussion state until we come to an
- agreement on *how* it should be implemented. -sdake

Many developers sit behind corporate firewalls and have to use http proxy settings / environment variables to reach any external network resources. Docker build process uses utilities like curl and yum that have options to set proxy server address -vbel

There are 3 working solutions I experienced to get Dockerfiles understand http proxies:
1) create a .proxy file that could be filled by user with relevant information (env vars):
  each time Docker build RUNs something prep-end it with source .proxy, e.g.
  RUN source .proxy \
          && yum install -y python-devel \
          && yum clean all
  at the end of Dockerfile the .proxy can be removed, e.g. by grand clean script :)
2) add ENV http_proxy %%HTTP_PROXY%% and similar to Dockerfile, allow build script to accept new argument. This approach works but is not clean since leaves ENV and there are no ways to unset these (Docker guys still discuss it)
3) add specific proxy settings to base images - can also go thru build script and tag,
e.g. proxy=%%HTTP_PROXY%% for /etc/yum.conf and /root/.curlrc . This is not flexible way - addition of one more getter will require tweaking of its config (e.g. for pip in source based builds)
 - vbel

I prefer 2nd option. If we are building whole stack behind corporate proxy, than we don't care about unset this (I think). That will be great if You add extra option in genenv, which will take care of setting proper variables in base Dockerfiles. That's only my opinion (: - mstachow

2nd option with ENV while being very easy does very bad job when images are started. http settings confuse many OpenStack services (I have met "no connection" while running Keystone, Glance...) - vbel

Yeah, I know about this. What's about NO_PROXY or something(based on LOCAL_IP for example) ? TBH the clearest way is configuring proxy via application, but You must configure each application - now It's easy, You've got Yum, PIP and Curl, but I can see Ubuntu in Gerrit and It's not our last word ;) - mstachow

Via application is the clearest, I agree, though we want to be flexible :) About NO_PROXY - we cannot specify network ranges with it, just suffixes:
http://unix.stackexchange.com/questions/23452/set-a-network-range-in-the-no-proxy-environment-variable
I will test something like NO_PROXY="*" to disable proxy settings. - vbel

I have tested no_proxy without much luck ('*' and ''), had to put it into all Dockerfiles with CMD at the end - not really convenient. keystone-manage db_sync fails immediately. Unsetting it in start.sh or kolla-common.sh also does not work because sometimes we run 'su' and ENV is preserved. One more solution would be tagged %%RUN%% that would become simple RUN or 'RUN export http_proxy=xyz && ' depending on script option. - vbel

#1 option can be more flexible to allow user supply various proxy settings in .proxy file - will be emply for "no proxy" users. Or we can rename it to something like .env to allow more configurable environment for build process - vbel

this may not even be necessary depending on what comes out of https://github.com/docker/docker/pull/9176
Using that patch and something like the parameter below in .buildconf allows one to build from behind a proxy.

BUILDFLAGS="--build-env=http_proxy=http://proxy:8080 --build-env=https_proxy=http://proxy:8080"

After that (Docker) has merged to master we just need a doc update on our end - harmw

The above pull request was rejected in favor of using https://github.com/docker/docker/issues/14634 - sdake

Latest idea for this (from irc) is to template in ENV sections at the top of Dockerfiles, then unset it in the start scripts (http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2015-08-11.log.html#t2015-08-11T16:11:19) -pbourke

Gerrit topic: https://review.openstack.org/#q,topic:bp/rhel-based-image-support,n,z

Addressed by: https://review.openstack.org/215541
    Add custom code to base docker templates

Gerrit topic: https://review.openstack.org/#q,topic:bp/add-proxy-to-dockerfiles,n,z

Addressed by: https://review.openstack.org/217678
    Add placeholder to unset http proxies

Addressed by: https://review.openstack.org/218190
    Add custom footer section to final image Dockefiles