The MirageOS Documentation

Agenda

• Improving Quality
• Error Handling RFC
• TLS merge progress
• OPAM 1.2 only
• GSoC Projects
• FOSDEM demo
• Bitcoin Piñata

Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, David Kaloper, Thomas Leonard, Jon Ludlam, Anil Madhavapeddy, Hannes Mehnert, Richard Mortier, Dave Scott, Mindy Preston and Nicolas Ojeda Bar

Notes

Improving Quality

We need to improve this in a more general and automated way. So far, we've done quite well with local library testing but we don't really have the ability to test things in coordinated way for unikernels. Specifically, we don't really have much end-to-end testing that looks at the complete toolchain. The only place where this surfaces for us is still mirage-www (this website!), as bugs tend to appear there whenever a wider issue occurs (cf. the recent crash on boot - mirage/mirage#375). Finding bugs in an automated way and reporting them is important as the project grows.

Some options include providing a manifest of specific versions and running tests that way. It would allow us to take different libraries and bisect issues. We would have to build this ourselves as we still have very few automated tests e.g is-mirage-broken (and it's not enough to just have tests — we also have to fix things that they show as broken).

Another thought is that instead of merging directly into the upstream OPAM repository (which is when we realise things aren't quite right), maybe we can merge into a staging repo and ensure they pass a bunch of additional tests. Provided tests pass, then the libraries can be merged upstream en-masse — in a known-working state. However, we must take care to balance things between staging and releases — we don't want to end up with a large backlog of 'unreleased' software and then do infrequent 'big-bang' releases. We need to test and release upstream often and no-one should have to add the staging remote just to use up to date software (that would merely shift the current problem from the main OPAM repo to our staging repo).

Related to the above, the ability to splice from an OPAM remote might be good (currently have to take everything on a remote). Perhaps ThomasG, Anil and Louis Gesbert can discuss at this. At the moment, trying to add test cases into libraries will make a big difference as an interim workflow. For example, Magnus has been patching TCP/IP to have some functional testing on Travis and we could do this for other libraries too, e.g DNS, Cohttp, etc and the approach would be useful elsewhere too. Getting some kind of Xen testing into mirage-skeleton would also be great.

Error Handling RFC

Thomas Leonard began a discussion on Error handling in Mirage and submitted a page to the website as an RFC. Since then, he's tried to document what people advocating for polymorphic variants were describing but, it would be better if other people can read it and advocate for their opinion (DavidK would take a look). There are also things from 4.02 that we might want to consider. In general, one of the themes that emerged from the discussions so far is the difference of Error-handling 'in the large' and 'in the small'.

OPAM 1.2 support only

The patch to the mirage tool has been made but not merged yet. ThomasG needs to get around to this and will do in due course.

TLS Merge progress

We are almost there with this and there are number of patches that need to be reviewed and merged (mirage/mirage-dev#52). The largest blockers are the blobs of C code and getting them to run on Mirage. The last mile still hasn't been covered as the entropy story is not yet complete — we need to get xentropyd out first. Currently it's not reliable enough as things start hanging. Once that's out of the way we're looking good. DavidK is working on it.

GSoC Projects

As part of Xen, we will be submitting projects as part of Google Summer of Code (GSoC). We've been curating a set of Pioneer Projects and we can definitely add to this list. A quick call for ideas resulted in several potential projects being proposed and these will be added to the projects page. Very briefly, we discussed:

• A router VM, which can route traffic and be a DHCP server.
• A syslog unikernel
• A Firewall
• OCaml SSH

Please see the Pioneer Projects page for more details.

FOSDEM Demo

Amir gave a demo at FOSDEM of a unikernel running on a Cubieboard2, that would serve the 2048 game when people connected to its Wifi access point. Mindy, Magnus and DavidK helped to get the Wifi bridge working and the demo was quite successful. There's a blog post describing the event and the repo is available with instructions on what to do. Several people expressed an interest in summer projects so they were directed to the Pioneer Projects page.

Bitcoin Piñata

Yesterday, saw the release of the Bitcoin Piñata, which is designed to draw more attention to the OCaml TLS stack and unikernels. Amir wrote a background post to provide some context around it and both of these appear to have spread very quickly over social media. The challenge is to break into a unikernel and recover the private key to a bitcoin address (and then make off with the bitcoins) — Hence the name, Piñata. If someone does manage to take the coins, we should see the transaction in the blockchain. Somewhat ironically, it seems that people have added some coins to the address (albeit only a small amount). The Piñata is due to be up for about a month, or until the coins are gone — the only reason for the time limit is due to the maintenance burden of keeping the site up and dealing with issues (cf. the site was subjected to a SYN flood the evening after it went live.).

--

AoB

• The next call is scheduled for Wednesday, 25th February - Please add any agenda items you wish to discuss in advance and refer to the mailing list for actual details a day or so in advance.