Hi, I don't know how Whirr works internally, but I guess that some "magic scripts" are run inside the EC2 instance and create the .xml Hadoop files. If I'm wrong on that, probably a solution could be:
* If DNS resolution worked, do as it is know: use the name reversed from the address * If DNS resolution didn't work, use the private IP address of the instance (you can know which is from inside the instance, I mean 'ifconfig | grep <something> | <awk something>'} Hope this could help... Best regards, ------ Fermín El 26/01/2012 18:22, Akash Ashok escribió: Do we really have to fail if reverse DNS resolution fails ? DNS resolution for my Indian IP always fails unless I use a proxy. So I suggest a warning output clearly mentioning the reverse DNS resolution failed and using the IP address instead ? Cheers, Akash A On Thu, Jan 26, 2012 at 10:30 PM, Andrei Savu <[email protected]<mailto:[email protected]>> wrote: Great! I'm starting to think that we should fail fast if DNS reverse resolution fails or improve the hadoop configuration builder. On Jan 26, 2012 6:04 PM, "Fermín Galán Márquez" <[email protected]<mailto:[email protected]>> wrote: Dear Andrei, I have changed DNS as you suggest, using Google's one, and now it works :) Thank you very much for your advice! ------ Fermín El 26/01/2012 0:25, Andrei Savu escribió: 2012/1/26 Fermín Galán Márquez <[email protected]<mailto:[email protected]>> How does Whirr obtain the IP address that it puts in the <value> of the fs.default.name<http://fs.default.name> property in the core-site.xml (and others)? Maybe knowing that could help to debug the issue of why Whirr is using the public IP (50.17.135.69 in this case) instead of the private one (10.*.*.*)... I have just checked the code. It seems like that if reverse dns resolution fails for the public IP you end-up with the raw public IP address in the config files. I think this is your case. Can you change the DNS servers on your machine? (e.g. to 8.8.8.8 & 8.8.4.4 - Google public DNS). In addition, I'm getting several "net.schmizz.sshj.transport.TransportException: Broken transport; encountered EOF" errors during "launch-cluster" process, but I think they are not relevant due to the cluster gets created at the end. Just mention in the case I'm wrong and these messages are meaningful. Red herrings - most of the time harmless - I think we need to update the logging settings to hide them. I'm going to file an issue for 0.7.1. ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at http://www.tid.es/ES/PAGINAS/disclaimer.aspx
