Support http proxy

[mzhidovinov]

Patterns Operator needs to support deployments that require the use of HTTP proxy to access the git repo (e.g. for initial cloning).

Two scenarios should be recognized:

1. There is a cluster-wide proxy configuration.
   Patterns operator needs to recognize and use resulting environment variables (e.g. HTTP_PROXY/HTTPS_PROXY/NO_PROXY).
2. The use of proxy is configured specifically for the Patterns Operator (e.g. for given repo)
   In that case, Patterns Operator may need to propagate the proxy configuration to the appropriate ArgoCD instances
   This may require support from validatedpatterns/common

[mbaldessari]

So part 1. is done via #190 . It will be part of the upcoming 0.0.45 release (will be a few days, because the community CI is currently down and it is required to release a new version).

[mbaldessari]

So I managed to cram it in to 0.0.44 which is out now. If you also update common/ in your project, cluster-wide proxy support should just work out of the box. Can you let me know if it all works for you as well? (I tested http proxy, https + custom ca and without proxy and they all worked okay for me). Thanks

[mzhidovinov]

Thanks a lot, I can confirm that it works for my case. I am testing with http proxy and standard RHCOS trusted CA bundle BR, Michael

…

On Tue, 16 Apr 2024 at 18:47, Michele Baldessari ***@***.***> wrote: So I managed to cram it in to 0.0.44 which is out now. If you also update common/ in your project, cluster-wide proxy support should just work out of the box. Can you let me know if it all works for you as well? (I tested http proxy, https + custom ca and without proxy and they all worked okay for me). Thanks — Reply to this email directly, view it on GitHub <#185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMXS74D5SEXKRY43F34DFDY5VBY7AVCNFSM6AAAAABF4T6QCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZGQYDQOJTGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mbaldessari]

Thanks Michael! So I was wondering what the use case for 2. is because it feels like we'd be adding quite a bit of code all over the place to support that (changes in the operator + common). It kinda feels very niche? I mean, if you have a proxy you must use then the whole cluster usually has to use it, I would expect.

[mzhidovinov]

It is common in many disconnected environments, e.g. there is no access to the outside and cluster wide proxy is not allowed by site security policy, but targeted proxy config is ok, e.g. specific subsystems like gitops or patterns-operator can be configured to use proxy. btw in many cases it will not be a proxy to the internet, but to the other side of the corporate network. Support for custom CA will be important. It is quite common scenario e.g. for telcos BR, Michael

…

On Fri, 19 Apr 2024 at 12:25, Michele Baldessari ***@***.***> wrote: Thanks Michael! So I was wondering what the use case for 2. is because it feels like we'd be adding quite a bit of code all over the place to support that (changes in the operator + common). It kinda feels very niche? I mean, if you have a proxy you must use then the whole cluster usually has to use it, I would expect. — Reply to this email directly, view it on GitHub <#185 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMXS73SFKQGVEOYME6CNADY6DPJHAVCNFSM6AAAAABF4T6QCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGE4DGNJYGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mbaldessari]

Thanks Michael, this is helpful! Btw. Custom CA is somewhat already there, just make sure that in your pattern CR you add extraCapabilities: initcontainers in the spec field and make sure you have the operator version at >= 0.0.44. Once you do that it will magically pick up the trusted-ca-bundle in all argo instances. The reason for it not being the default is that we're still testing a few scenarios.