© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
a60fb26
(Get the code!)
John,
> It seems like we could have a meta setting, but it may be better to just add individual settings for all the other ones.
After poking around it some more I think it would be good to have the following:
1) individual HTTP/HTTPS proxy settings for every destination where juju is an HTTP client (image-stream, agent-stream, juju gui binaries, juju HA peer http connectivity, substrate HTTP API, charm store API);
2) individual HTTP/HTTPS settings for apt, snapd, lxd.
Right now we have a problem with using no-proxy even though it does not land in /etc/environment because we need to handle local connectivity (HA peers, client -> controller, substrate API) vs remote connectivity (cloud-
no-proxy just becomes too large for us to handle and we run out of stack memory.
apt proxy settings can be set separately but agent binaries have to be downloaded via a proxy (we do not always do mirrors).
agent-metadata-url only provides a way to specify a mirror, not a proxy. Mirrors (apt mirrors, snap store, image mirrors) and proxies are not mutually exclusive though so a tuple per http destination would be good.
no-proxy just becomes too large for us to use as it has to include hostnames and does not universally support CIDR.
I think we are not so worried about configuring deployed applications to use proxy settings via global options - this can be done by charms. As for our daemons, we could leverage CIDR and wildcard support for http(s) proxies in golang if it ever gets landed in addition to individual options:
juju - golang
snapd - golang
lxd - golang
https:/
https:/
https:/