In the past I may have agreed with you, but Juju did change for a reason.
Originally Juju just supported the http_proxy type model config, and those values were written to the machine's /etc/environment.d directory to be included in the standard system environment, but there were too many weird edge cases to support around that behaviour.
New model config variables were introduced prefixed with juju_ (juju_http_proxy and its ilk). These configuration values were exported as part of the charm environment (including the JUJU_ prefix). It was then up to the charm to decide whether to use the proxy or not. Sometimes the charm knew that for internal communication, no proxies were used, and the proxy was only needed for access outside the model.
For this reason, Juju does not automatically set the proxy variables for any workload. If the charm knows that it needs to use the proxies if they are there, then it should be the charm's responsibility to set the proxy variables in the podspec for the container.
Hi @David,
In the past I may have agreed with you, but Juju did change for a reason.
Originally Juju just supported the http_proxy type model config, and those values were written to the machine's /etc/environment.d directory to be included in the standard system environment, but there were too many weird edge cases to support around that behaviour.
New model config variables were introduced prefixed with juju_ (juju_http_proxy and its ilk). These configuration values were exported as part of the charm environment (including the JUJU_ prefix). It was then up to the charm to decide whether to use the proxy or not. Sometimes the charm knew that for internal communication, no proxies were used, and the proxy was only needed for access outside the model.
For this reason, Juju does not automatically set the proxy variables for any workload. If the charm knows that it needs to use the proxies if they are there, then it should be the charm's responsibility to set the proxy variables in the podspec for the container.