This was discussed in Vancouver but we keep getting bitten by this, so I'm opening a bug to track it.
Juju should provide some form of DNS to ensure that charms can get consistent, resolvable, and reverse-resolvable names for the units. The behavior of providers is very inconsistent. Most give something like a host name for the private-address of a remote unit but some give IPs. And for `unit-get private-address`, sometimes it's resolvable on the unit in question but not from other units. This will only become more of an issue in the future with cross-model relations.
This comes up in big data because a lot of the software is Java-based and requires host names in their config that can both be resolved to an IP and have that IP reversed back to the host name. The Bigtop charms currently don't work on Joyent because it doesn't provide any DNS service like most other clouds.
Another use-case that the Hadoop charms run up against is that the software uses the configured host names to generate links in the web UIs and, even when they work internally, they're not resolvable from outside the cloud.
Resolving this in the charm is prohibitive. We worked around it in the previous iteration of Hadoop charms by passing around the list of host entries and populating them in /etc/hosts, but that became unwieldy quickly. There is a prototype DNS charm but it isn't maintained and since this is something that almost every charm will care about, it would quickly become something that every charm would need to support. It couldn't even be handled in a generic way because it would lead to race conditions in the charms.
My suggestion is to have Juju run a split-horizon DNS on the controller which would handle only domains of the form <unit>.<service>.<model>.<controller>.juju and <service>.<model>.<controller>.juju. The units would be automatically configured on bootstrap to use that DNS, which would resolve those names to the internal IP of the given unit or leader of the service, respectively. The Juju client could also automatically (optionally?) add that server to the client, and it would resolve those names to the public IPs of the unit or service leader.
I think the idea of <application> for an entry is a bit much. How should that be handled? Is it all the addresses as A/CNAME entries for round-robin, or is it just the leader? To keep this solution and implementation simple/clean it should just be a mapping at the lowest level, the unit.
Furthermore, the model UUID should be the TLD. If we use .juju as a tld we run into the potential problem of that conflicting if juju ever becomes a TLD (don't scoff, this has already bitten a lot of people with other TLDs).
I'd expect, to start, something such as unit-<APPLICATI
The final, potential, problem is we'd be overriding the DNS lookup values with cloudinit, making the controller(s) the nameserver for the deployment. This means that the controller will also have to properly handle DNS forwarding or we'll run into a lot more problems.