[
https://issues.apache.org/jira/browse/WHIRR-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424452#comment-13424452
]
Adrian Cole commented on WHIRR-604:
-----------------------------------
actually, jclouds NodeMetadata.hostname is just that: the hostname of the
machine (doesn't necessarily imply DNS)
in clouds like EC2, the public (and private) dns names are supplied via api call
http://docs.amazonwebservices.com/AWSEC2/latest/APIReference/ApiReference-ItemType-RunningInstancesItemType.html
so..
Instance.getPublicHostName actually attempts DNS resolution, so we can safely
assume it is intended to be a DNS name
Instance.getPrivateHostName is deprecated for some reason, so I presume we are
to use for Instance.getPrivateIp in configuration needing LAN communication.
If I'm correct(ish) so far, than the DnsResolver class could get us out of the
problem where we don't know the correct value of the DNS name. Ex. failing DNS
resolution, it could just fallback to x-x-x-x.static.cloud-ips.com, as there's
nothing rackspace specific about that. Failing that (ex. in private clouds),
or per override, publicHostname could be alternately specified.
and again.. we'd end up setting this to the correct value on the machine via
configure_hostnames.sh
If we validate a general logic to apply, I think we can get rid of
provider-specific logic completely.
Summing up above:
1. configure_hostnames.sh has the responsibility of adding
instance.publicHostname, such that it resolves locally.
2. the responsibility of setting instance.publicHostname to a valid value is
Whirr. This logic follows the following
* if an override is specified, set instance.publicHostname to that
* if publicIp resolves via dns, return that.
* if x-x-x-x.static.cloud-ips.com resolves via dns, return that
* else return nodeMetadata.getHostname()
> Non-resolvable hostnames should be reset to something resolvable
> ----------------------------------------------------------------
>
> Key: WHIRR-604
> URL: https://issues.apache.org/jira/browse/WHIRR-604
> Project: Whirr
> Issue Type: Bug
> Components: core
> Affects Versions: 0.7.1
> Reporter: Andrew Bayer
> Assignee: Adrian Cole
> Fix For: 0.8.0
>
>
> So we currently have a hack in
> core/src/main/resources/functions/configure_hostnames.sh to reset the
> instance hostname on Rackspace to a-b-c-d.static.cloud-ips.com, since the
> hostname on the instance that Rackspace uses either isn't resolvable at all
> or isn't resolvable externally (not 100% sure which is the case there - I
> think they're just not resolvable). This logic should be generalized, since
> there are other providers where this is the case, and it's also an issue
> with, say, something like a private Cloudstack install.
> What seems to make sense is to add a property - something like
> whirr.ip-hostname-domain - and to add a check if we can actually resolve the
> instance's hostname from anywhere but that particular instance (since the
> very fact of it being in /etc/hostname means it'll be resolvable locally). If
> not, set the hostname to a-b-c-d.${whirr.ip-hostname-domain}, with logic in
> Java somewhere to have a mapping of known provider->ip hostname domains for
> cases like Rackspace, so that whirr.ip-hostname-domain doesn't need to be set
> explicitly in those cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
