Charm uses juju-http-proxy config, but not honor juju-no-proxy

[Drew Freiberger]

When a juju model has juju-http-proxy and juju-https-proxy variables set, and juju-no-proxy is also set, the charm configures the proxies in /etc/landscape/client.conf, but does not set no-proxy nor check that the ping-url and/or url IPs are within the juju-no-proxy configuration.

For instance, if I have:

juju-http-proxy controller http://10.0.0.1:8000
juju-https-proxy controller http://10.0.0.1:8000
juju-no-proxy model localhost,127.0.0.1,::1,10.0.0.0/8

And my url is http://10.0.0.2/message-system and ping-url is http://10.0.0.2/ping, the http-proxy and https-proxy configs end up in /etc/landscape/client.conf, which then forces client registration to happen through the proxy, even though the 10.0.0.2 is within my juju-no-proxy CIDR.

This variable must be parsed and managed by charmers to go hand-in-hand with the use of juju-http(s)-proxy variables.

A workaround is to define http-proxy and https-proxy in the charm config as blank strings with:
juju config landscape-client http-proxy="" https-proxy=""

It seems that if these are "unset" as the default config, then the juju model variables are utilized, but if set to null strings, the juju model configs are ignored and these variables are left unset in the client.conf template.

[Drew Freiberger (afreiberger)]

This issue is mainly in relation to on-premise landscape-server usage. using the proxy for access to hosted landscape as a service makes sense for most use-cases.

[Przemyslaw Hausman (phausman)]

Confirmed on a recent ussuri-focal deployment. Thank you @afreiberger for the workaround!

[Xav Paice (xavpaice)]

Also affects if the model-config uses the 'legacy' http-proxy, https-proxy and no-proxy settings.