Hi Naresh,

I spoke too soon: http://validation.linaro.org/lava-server/scheduler/job/34953/log_file

Andy: When you get online could you look at this? We are now getting to the submit results bit, but that is timing out. Any clues?

Thanks

Dave

On 9 Oct 2012, at 14:06, Dave Pigott dave.pigott@linaro.org wrote:

Hi Naresh,

This is now fixed due to another change checked in this morning and the boards are running their health jobs. Once they've completed your jobs should then run.

Thanks

Dave

On 9 Oct 2012, at 11:54, Naresh Kamboju naresh.kamboju@linaro.org wrote:

...

Hi,

Following jobs submitted to test BL core test and they are not started. I request you to debug the reason for test not started. These results needs to be published as weekly BL core test report

http://validation.linaro.org/lava-server/scheduler/job/34929 http://validation.linaro.org/lava-server/scheduler/job/34931 http://validation.linaro.org/lava-server/scheduler/job/34952

Best regards Naresh Kamboju _______________________________________________ linaro-validation mailing list linaro-validation@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-validation

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.

On 10 October 2012 12:46, Dave Pigott dave.pigott@linaro.org wrote:

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.

if it work from now onward. then it is a permanent fix.

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

if all device connected are having updated /etc/hosts then every thing is

fixed.

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.