manual provider talks to itself on unpredictable, unconfigurable port

[Aaron Bentley]

In addition to the configurable provider storage port, juju uses another apparently-random port for machine-0 to talk to itself. When that port is denied due to firewall rules, you get this:

2014-02-20 21:32:41 ERROR juju.cmd supercommand.go:293 cannot upload charm to provider storage: Put https://54.227.159.240:52324/wordpress-21-df9ace20-114d-4c88-8d89-235417b7e998?authkey=dac7e6fe-703d-4f52-82db-1023646bffde: dial tcp 54.227.159.240:52324: connection timed out

In this case the storage-port was set to 8040, and this was successfully used for bootstrapping, but charm uploads attempted to use 52324 instead.

As I understand it, these uploads are from the bootstrap machine in its role as machine-0, to itself, in its role as the provider.

Firewall rules that prevent a machine from uploading to itself on high ports are rare. We encountered this case on ec2, which is not a common use case.

I suggested that we could just use localhost, but Kapil pointed out that this would not be suitable once HA is implemented, because machine-0 and the provider machine may be different. However, I believe that in this case, it's also necessary that all connectivity requirements be documented, because whatever port machine-0 uses to communicate with the provider must be permitted by the router.

I am marking this low because at this point, only ec2 appears to be affected, and that is not a sane use case. (The solution on ec2 is to use the instance domain name rather than the ip address-- for ec2 instances, this domain name resolves to the internal IP, and high-port access on the internal IP is permitted.)