On 10 October 2012 12:46, Dave Pigott <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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. >> >> > >
_______________________________________________ linaro-validation mailing list [email protected] http://lists.linaro.org/mailman/listinfo/linaro-validation
