search

fxbox / dns-server

Server that helps the Box to announce its local IP address without relying on mDNS, and to register its LetsEncrypt cert for use on its local IP address.
4 stars 2 forks source link

Store logs on the server #11

Open JohanLorenzo opened 8 years ago

JohanLorenzo commented 8 years ago

Yesterday, the E2E test started to fail for no obvious reasons. Locally, I noticed that sometimes 2 boxes are visible from http://fxbox.github.io/app/ . I'm suspecting Travis to share the same internal IP address on many VMs.

I got the live logs on the knilxof (ssh login then pm2 logs $APP_NAME - thanks @samgiles :smiley:) machine, but I couldn't find if the logs are already stored on the hard drive. If not, that's something we could improve. What do you think @michielbdejong @samgiles ?

cc @isabelrios @npark-mozilla

michielbdejong commented 8 years ago

Yeah, it makes sense if concurrent travis runs would see each other's boxes, that's also what would happen (and we have seen this happen) if you have >1 boxes in for instance a Mozilla office. So to fix the root problem of testing on Travis, either write a test that is robust against seeing "neighbor" boxes appear, or see if we can apply some more advanced Travis fu (e.g. http://stackoverflow.com/questions/18493149/travis-ci-static-ip-for-the-vm).

About logging on knilxof.org, I would expect pm2 logs to be enough, IIRC it will show the logs for the entire uptime?

I'm hesitant to build logging to disk into the dns-server application as a feature, because of NSA sub-poena's for these logs.

For debugging, you could also run the dns-server locally, then you know you're the only user on there.

Maybe you could even put the dns-server into the travis image? Is the travis image currently relying on the knilxof.org instance of dns-server? If so, then that's not really an e2e test, I would say, since dns-server is part of the system being tested, right?