Github user aledsage commented on the issue:
https://github.com/apache/brooklyn-server/pull/869
For #849's change, the reason the code used the "public-hostname" for both
public and private hostname sensor in AWS was because that hostname is
resolvable in both (inside the region it resolves to the private ip, and
outside the region it resolves to the public ip). That was true for
aws-classic. I suspect that for VPCs and private subnets, it's less true - but
probably worked because we'd fail to get the hostname and would log.warn and
fallback to using the IPs.
Completely agree with your observation @Graeme-Miller that we can't trust
`node.getHostname()` (unless we start putting cloud-specific code back in
again).
---
The concern with these changes is that people must know which sensor to
use: for example, will the app be used from inside the same region or from
outside. For example, that's a problem when you run a demo in GCE - the URL
advertised at the top-level app is often the subnet ip. Do these changes mean
we'll have the same problem demo'ing in AWS?
Arguably we should solve that problem at the app-level, to say explicitly
which URL(s) to advertise (as described in Alex's proposal for `.public` sensor
name suffixes etc).
Overall I'm fine with this change, as long as it doesn't make demos /
getting-started harder by advertising "main.url" as the internal IP of nginx in
a three-tier app deployment to AWS!
---
