Whirr
  1. Whirr
  2. WHIRR-511

Instance.getPrivateHostName returns an IP address

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.8.0
    • Fix Version/s: 0.8.0
    • Component/s: core
    • Labels:
    • Environment:

      AWS m1.large

      Description

      getPrivateHostName returns the same thing as getPrivateIp. I would expect to get something like "ip-42-142-142-142.ec2.internal" as is reported by the AWS console.

      Instance.getNodeMetadata().getHostname() returns the actual `hostname` as reported by the OS of the instance (which worked for me).

      Not sure if this is expected behavior, or if it's a JCloud issue, or what. Feel free to mark invalid

        Issue Links

          Activity

          Hide
          Andrei Savu added a comment -

          Very good point! I think we should delegate as much as possible those calls to nodemetada. Right now this is happening because we attempt to do reverse DNS resolution - and as expected it fails - and it returns the raw IP address. I will make the needed changes.

          Show
          Andrei Savu added a comment - Very good point! I think we should delegate as much as possible those calls to nodemetada. Right now this is happening because we attempt to do reverse DNS resolution - and as expected it fails - and it returns the raw IP address. I will make the needed changes.
          Hide
          Andrei Savu added a comment -

          I have done a bit of investigation on this and it seems like there is no sensible way of retrieving the reverse DNS name for a private IP and I think we shouldn't even attempt that. For EC2 the hostname can be used as the reverse DNS name for the private IP but unfortunately the same it's not true for cloudservers.

          Show
          Andrei Savu added a comment - I have done a bit of investigation on this and it seems like there is no sensible way of retrieving the reverse DNS name for a private IP and I think we shouldn't even attempt that. For EC2 the hostname can be used as the reverse DNS name for the private IP but unfortunately the same it's not true for cloudservers.
          Hide
          Andrei Savu added a comment -

          One way to move forward is by fixing cloudservers by updating /etc/hosts & the hostname as needed + /etc/resolv. What do you think? We already have a script that does this for Hadoop configure_hostnames. Should we apply this for all services? (like a statement add by Whirr core on bootstrap?)

          Show
          Andrei Savu added a comment - One way to move forward is by fixing cloudservers by updating /etc/hosts & the hostname as needed + /etc/resolv. What do you think? We already have a script that does this for Hadoop configure_hostnames. Should we apply this for all services? (like a statement add by Whirr core on bootstrap?)
          Hide
          Andrei Savu added a comment -

          Another way to do handle this on cloudservers is to set the machine hostname the same as the public hostname.

          Show
          Andrei Savu added a comment - Another way to do handle this on cloudservers is to set the machine hostname the same as the public hostname.
          Hide
          Alex Heneveld added a comment -

          Why do we need the private hostname?

          We might conceivably need private IP or public IP, although even that is risky (quite a leaky distinction). In general seems best to me to use public hostname and expect (require) that to resolve correctly. So if any action from this issue let's remove "private hostname".

          Patch to #459 means public hostname is returned correctly more often, either by DNS resolution or jclouds metadata. (If there are gaps let us know, but probably they should be fixed in jclouds...)

          Show
          Alex Heneveld added a comment - Why do we need the private hostname? We might conceivably need private IP or public IP, although even that is risky (quite a leaky distinction). In general seems best to me to use public hostname and expect (require) that to resolve correctly. So if any action from this issue let's remove "private hostname". Patch to #459 means public hostname is returned correctly more often, either by DNS resolution or jclouds metadata. (If there are gaps let us know, but probably they should be fixed in jclouds...)
          Hide
          Andrei Savu added a comment -

          We might conceivably need private IP or public IP, although even that is risky (quite a leaky distinction). In general seems best to me to use public hostname and expect (require) that to resolve correctly. So if any action from this issue let's remove "private hostname".

          +1

          Show
          Andrei Savu added a comment - We might conceivably need private IP or public IP, although even that is risky (quite a leaky distinction). In general seems best to me to use public hostname and expect (require) that to resolve correctly. So if any action from this issue let's remove "private hostname". +1
          Hide
          Adrian Cole added a comment -

          Here's more context:

          NodeMetadata.getHostname is Nullable, when the backend api doesn't return data for hostname.

          jclouds doesn't filter the data the api returns, so if an ip address is returned, that would end up in the field. jclouds could add a sanity check and null it out, if the api returned an ip address.

          As hostname assignment is performed in most clouds by commands on the image itself, it is possible for a custom image to screw this up, even on a provider that usually sets hostnames. As such, any code that uses node.hostname should probably treat it as "best efforts". This is basically what NodeMetadata.getHostname javadoc says.

          This glitch is checked in the assertion here in the jclouds codebase:
          BaseComputeServiceLiveTest.checkResponseEqualsHostname

          The above ensures that the hostname command corresponds with what's returned from the api. This is overridden by cloud providers who either don't return hostnames, or use images do not assign the hostname properly. jclouds could break this test up slightly to only bother checking the hostname command, if the node.hostname field is set. This would make it more easy to show providers or images which are faulty in this regard.

          Show
          Adrian Cole added a comment - Here's more context: NodeMetadata.getHostname is Nullable, when the backend api doesn't return data for hostname. jclouds doesn't filter the data the api returns, so if an ip address is returned, that would end up in the field. jclouds could add a sanity check and null it out, if the api returned an ip address. As hostname assignment is performed in most clouds by commands on the image itself, it is possible for a custom image to screw this up, even on a provider that usually sets hostnames. As such, any code that uses node.hostname should probably treat it as "best efforts". This is basically what NodeMetadata.getHostname javadoc says. This glitch is checked in the assertion here in the jclouds codebase: BaseComputeServiceLiveTest.checkResponseEqualsHostname The above ensures that the hostname command corresponds with what's returned from the api. This is overridden by cloud providers who either don't return hostnames, or use images do not assign the hostname properly. jclouds could break this test up slightly to only bother checking the hostname command, if the node.hostname field is set. This would make it more easy to show providers or images which are faulty in this regard.
          Hide
          Tom White added a comment -

          I don't think private hostnames are used in any of the services. ZooKeeper uses private IPs for communication within the ensemble, but IPs are fine. So deprecating, then removing in a future release would be OK. Note that you can still use Instance.getPrivateAddress().getHostName().

          Show
          Tom White added a comment - I don't think private hostnames are used in any of the services. ZooKeeper uses private IPs for communication within the ensemble, but IPs are fine. So deprecating, then removing in a future release would be OK. Note that you can still use Instance.getPrivateAddress().getHostName().
          Hide
          Andrei Savu added a comment -

          I'm preparing a patch now.

          Show
          Andrei Savu added a comment - I'm preparing a patch now.
          Hide
          Andrei Savu added a comment -

          Here is the patch. I've marked the method as deprecated and short-circuited DNS resolution.

          Show
          Andrei Savu added a comment - Here is the patch. I've marked the method as deprecated and short-circuited DNS resolution.
          Hide
          Andrei Savu added a comment -

          Committed to trunk. Hadoop works fine for me with on EC2 with AMI ami-0baf7662 (Ubuntu 10.04 LTS Lucid).

          Show
          Andrei Savu added a comment - Committed to trunk. Hadoop works fine for me with on EC2 with AMI ami-0baf7662 (Ubuntu 10.04 LTS Lucid).

            People

            • Assignee:
              Andrei Savu
              Reporter:
              David Arthur
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development