• View
• Edit
• History
• Print

FAIL

Using FAIL*

January 19, 2016

Need to know a lot for this one.

I'm trying to get up and running with FAIL* (papers, github).

They provide a Docker... image? I don't know what anything is called for Docker. Docker is containers (instead of VMs) mixed with github. A pain to learn, but actually pretty slick. One container has a MySQL sever to record the results, there is also a server and a client? Still figuring it out.

Docker commands (run everything as sudo...):

  docker ps
  docker ps -a
  docker run <...>
  docker start <name>
  docker stop <name>
  docker rm <name>

MySQL commands:

  show databases;
  use [db name];
  show tables;
  SELECT * FROM [table name];

The "interesting" tables made when running FAIL*: trace, fsppilot, fspgroup

But the easier way to view the results is to run make resultbrowser in the fail-demo container, and then pointing a web-browser to http://0.0.0.0:5000/.

Following the directions and using the Makefile in <fail repo>/scripts/docker/ works well for the first run. To start the demo again, one can use:

  docker start fail-db
  docker start fail-demo
  make ssh-fail-demo

I tried out the demo and then made some small code changes. What was most illustrative was the code that did not make any difference in output. I don't fully understand how the testing is done, and would need to dig into how their experiments are configured and executed if I wanted to really use this tool. One thing I did notice was that even small programs can take a long time to simulate, at least on my laptop. I can see why their architecture is designed to take advantage of clusters.

There is a lot to FAIL*, and I appreciate how easy it is to get a demo up and running. Unfortunately, it looks like it will not be suitable for my needs. It may be of use to validate small sections of code, such as code paths in the voter, but unlikely to be able to answer questions about code making system calls and using libraries.