After reading the RFC I think that more robust and adaptable solution would be better. A single env var is not going to cover the needs of all the scenarios. A simple example may be accessing both registry.access.redhat.com (through proxy) and myopenshift:5000 (no proxy).
As @jlsherrill noted on the PR, the temporary solution for the foreman-docker plugin is alright for the moment. On Wed, May 17, 2017 at 3:08 AM, Sebastian Gräßl <[email protected]> wrote: > There was some feedback regarding this on the PR[1] mentioned in the > beginning. > There is already a RFC[2] regarding this and a plugin[3] to implement the > solution proposed in the RFC. > > The solution proposed by jlsherrill allows to add multiple HTTP-proxies in > Foreman and use these in plugins and allow to configure what HTTP-proxy > should be used for what requests. > So far the plugin only adds the ability to add HTTP proxies and misses a > essential part, which is applying the HTTP proxies to requests. > > While looking at how other applications handle this and also considering > typical HTTP proxy configurations, it feels that such a solution would make > it rather complex in practice to apply. Configuring rules for requests or > just ensuring the proper request is using the right HTTP proxy is better > configurable in the HTTP proxy itself. > > I believe a very bold simple solution would be the better, which in my > opinion would be to ensure all parts respect a HTTP proxy configuration and > have good documentation around it to advice on how to configure the HTTP > proxy correctly. Taken other applications in the same area the HTTP_PROXY > environment variable seems to be the common standard to use. > > Please, I would love to hear more feedback on this and what are common > HTTP proxy setups. > > [1] https://github.com/theforeman/foreman-docker/pull/189 > [2] https://github.com/theforeman/rfcs/pull/18 > [3] https://github.com/jlsherrill/foreman_http_proxies > > On Thursday, April 20, 2017 at 1:07:33 PM UTC+2, Sebastian Gräßl wrote: >> >> Hej, >> >> at the moment there is a PR[1] open on foreman-docker to set a HTTP proxy >> for requests to registries. >> The PR allows to set a HTTP proxy on the HTTP client, in this case deep >> down Excon, only for registry requests. >> >> A HTTP proxy won't be set on requests if a `HTTP_PROXY` environment >> variable is available, since it is an unlikely setup to have registry >> request routed over a different proxy than other requests. However setting >> it via the environment variable will allow requests to succeed to resources >> available by the HTTP proxy, but will fail for those inside and possible >> blocked. >> >> The `HTTP_PROXY` environment variable seems to be a standard, and >> therefore Excon is built to use it when available. >> Excon is used by docker-api as well as fog, it might be used by other >> components and there might be other parts that use another HTTP client like >> RestClient, which also respects the variable. >> >> This means at the moment with that environment variable set some requests >> would already rely on it. >> In any case this should be in mentioned in the manual to be aware of, >> also because some operating systems set this globally. >> >> The question is should we make an afford to ensure deployment behind a >> HTTP proxy on a system with HTTP blocked works without issues and provide a >> way to configure it properly? >> >> I've tested Foreman with HTTP blocked and `HTTP_PROXY` set, but in a very >> basic setup, with the only external requests being to Docker registries >> outside and squid configured to just pass requests through regardless there >> to. >> >> It didn't show any apparent issue, but there are for sure issues with a >> more robust configured HTTP proxy. >> This raises another question: How common is a setup where external >> resources requiring HTTP are used with Foreman behind a HTTP proxy? >> >> Comments? >> >> All the best, >> Sebastian >> >> [1] https://github.com/theforeman/foreman-docker/pull/189 >> >> -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
