Note that most applications require you to list *every* IP address that you don't want to proxy separately *or* create a Domain and only reference things via the Domain Name.
See bugs like https://bugs.launchpad.net/juju/+bug/1421650
If we *could* we'd set no_proxy with nice short-form CIDR notation around what spaces (subnets) we are deployed in, which would leave you with a reasonably short list.
We could try to do "no_proxy everything in the model" and hope you never have 1000s of machines. (Note that no_proxy becomes an O(N^2) problem as everytime you deploy a new machine, you now have to tell all the other machines that they shouldn't proxy traffic to that machine.)
We could try "no_proxy everything related to units on the machine" which ignores some realities, but would at least keep N smaller. (Still N^2 in the number of machines with units related to each-other.)
Its a similar problem that they ran into with Hadoop, where everything *had* to be a Hostname, which meant they were populating /etc/hosts with the 100 machines that were being spun up for the hadoop charm. The problem is still that a given application can have 100 machines.
One option would be to re-open the idea of Juju becoming a DNS server, and giving a common suffix to every machine in the model, and only configuring traffic between machines to use the DNS names.
That is a rather major overhaul of the communication model to handle no_proxy.
Note that most applications require you to list *every* IP address that you don't want to proxy separately *or* create a Domain and only reference things via the Domain Name. /bugs.launchpad .net/juju/ +bug/1421650
See bugs like https:/
If we *could* we'd set no_proxy with nice short-form CIDR notation around what spaces (subnets) we are deployed in, which would leave you with a reasonably short list.
We could try to do "no_proxy everything in the model" and hope you never have 1000s of machines. (Note that no_proxy becomes an O(N^2) problem as everytime you deploy a new machine, you now have to tell all the other machines that they shouldn't proxy traffic to that machine.)
We could try "no_proxy everything related to units on the machine" which ignores some realities, but would at least keep N smaller. (Still N^2 in the number of machines with units related to each-other.)
Its a similar problem that they ran into with Hadoop, where everything *had* to be a Hostname, which meant they were populating /etc/hosts with the 100 machines that were being spun up for the hadoop charm. The problem is still that a given application can have 100 machines.
One option would be to re-open the idea of Juju becoming a DNS server, and giving a common suffix to every machine in the model, and only configuring traffic between machines to use the DNS names.
That is a rather major overhaul of the communication model to handle no_proxy.