Hi Naresh,

Fixing this in each /etc/hosts is a workaround, but making the local DNS resolve the address centrally to the LAN address is a fix, since it is a single change that does not have to be "remembered" every time we deploy a new instance/server or whatever but will work from there on.

What are you suggesting is a permanent fix, given that this is about lab infrastructure and not an issue with LAVA?

Thanks

Dave

On 10 Oct 2012, at 05:08, Naresh Kamboju <naresh.kamboju@linaro.org> wrote:

Hi Andy,

Now my jobs are resumed and started execution. Both rtsm_ve-a15x4-a7x4_01 and rtsm_ve-a15x4-a7x4_02 are online now.

I think the fix given below is a work around. I request you to give a permanent fix.

Thank you.

Best regards

Naresh Kamboju

On 9 October 2012 20:26, Andy Doan <andy.doan@linaro.org> wrote:

So fastmodels are back online. Dave and I just worked through the issue, but I wanted to mention it so everyone's aware of it:

The health jobs were running just fine, but the submission of results to the dashboard were failing. I saw this same issue yesterday on control, so I had a good idea of the workaround.

All the systems in the lab can do a proper DNS lookup of validation.l.o. However, they can't get to port 80 on validation.l.o. I think this is probably because our new router works differently than our old router. On the old router, it would accept requests on both the internal and external network to port 80 and then forward that to the proper internal IP. On the new router, it appears to only handle port forwarding requests from external IP's.

The way around this is to have validation.l.o resolve to the internal IP address on our network. For now, I've done this in the /etc/hosts files of control and fastmodels01. However, I'm also going to set this in our DNS server so that we don't have to carry around that baggage going forward.