Comment 5 for bug 1883656

> If I recall correctly, the juju proxy settings were specifically designed not to be used to interfere with the system wide proxy settings.

Yes, that is the current implementation and intent of my patch as well. I am not suggesting we automatically inject these settings into the environment of every process or service - this is bad for sure.

> I haven't got specific examples I can relate as the the issues that were encountered

There were 2 issues originally:

1) auto-injection of environment variables into the default service and shell environments.
2) auto-injection of environment variables that modify http client behavior into the *hook environment*;

(1) got addressed by writing to files not picked up by any tooling automatically (just files under /etc/):

/etc/juju-proxy-systemd.conf # (this file needs to be symlinked manually to be used per the comment here https://github.com/juju/proxy/blob/master/proxy.go#L108-L110)
/etc/juju-proxy.conf # this file needs to be sourced manually to be used

(2) got addressed by adding proxy settings with a "juju-" prefix and JUJU_CHARM_* environment variables in hook environments.

However, (1) is currently only done for legacy proxy settings, not the new proxy settings.

a) on initial startup via the cloud-init-userdata;
https://git.io/JfdGL

b) by proxy-updater worker on any changes to model config
https://git.io/JfdsA
https://git.io/Jfdsp (note: the comment here is old, settings are not written to /etc/systemd/system.conf.d or /etc/systemd/user.conf.d nowadays for legacy proxy settings)
https://git.io/JfdGj (likewise, only done for legacy proxy settings).

My patch was an attempt to have the above behavior for new proxy settings as well since it doesn't affect processes globally (I only addressed (a) but missed (b) in the current version of the PR).

The reason is the lack of a way to track proxy setting updates:

* there is no hook for that currently: we would have to track updates at the charm library level on every hook execution;
* proxy worker updates are asynchronous to the hook execution - there will always be a lag between when they get updated and hook execution (update-status executes every 5 minutes by default).