and developer guides
Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, Heidi Howard, David Kaloper, Masoud Koleini, Thomas Leonard, Hannes Mehnert, Richard Mortier, Nicolas Ojeda Bar, Mindy Preston and Magnus Skjegstad
There was a meeting of the test breakout squad, which included Mort, Mindy, David Scott, Magnus and ThomasG. There was a long discussion last week and they covered a variety of items, such as reproduction of issues, component tests and other things. There's room for improvement everywhere!
There are some useful things to get started with, for example simply documenting assumptions in stack would a step forward (e.g. blocking vs non-blocking, etc). It would also be helpful to define best practise and we can look to certain libraries for this (cf. Dave and Vchan).
There are several actions that arose from the test meeting and Mort has notes that he'll write up when he gets a chance.
ThomasL also noted that Travis has a new build cluster on Amazon, as long as
sudo
is not needed. It would speed things up if we can we get PPA added to
that.
ThomasG is reworking the the watch API. Added two functions and is adding unit tests too. The API is still not settled as ThomasL has posed questions that need to be addressed. The new LCA code is much faster though.
Although ThomasG is currently focused on Watch, merge is the big thing missing at the moment. ThomasL is specifically waiting for for support for this and it's the main thing he needs before he can 'release' CueKeeper to others.
Jitsu will be presented at NSDI in less than a month. There haven't been many updates since last time, though work is taking place to add libxl support (and keep support for both libvirt and libxl). The code that exists in the main branch can can be used and is the version we used for the experiments in the upcoming paper. It's stable but currently a bit difficult to use. Should try and improve this before the presentation itself, so Magnus needs to make some releases. Amir is preparing a news release to coincide with the NSDI talk and will circulate off-list for feedback.
We had a brief discussion about trying to decouple the releases of libraries
from the mirage
tool itself.
We're not in a good place at the moment as we can't release a number of
libraries without also having to update and release a new version of mirage
too. Currently there is no way to set constraints in the Mirage tool itself,
which leads to a situation where a number of new libraries may be available in
OPAM but the Mirage tool cannot use them — i.e. there are packages that are
more recent than mirage
knows about. Therefore the Mirage tool becomes a
bottleneck. There are many libraries that are in this situation, so this is
not an isolated case. The opinion at the moment seems to be to push the onus
of updating mirage
onto the maintainer of the respective repos, but this has
it's own issues (and failure modes).
This is something that we will need to discuss further so we should bring it up on the next call.
DavidK still working on this! Ask again in two weeks.
A question came in by email about hosting a public hangout for people who may be interested in learning more about unikernels and MirageOS. One of the points that occurred to us was whether this is a repeat of the written information we already have, a Q&A with the developers, or a wider-ranging discussion about where MirageOS and unikernels are going. All are valid areas but serve different audiences and require different attendees/prep.
In general, it was felt that this would be A Good Thing, as long everyone can get something out of it. For example, it would be great for us to hear of use-cases and we could record the session and post it to the website as further material. It would also allow us to correct any misconceptions about unikernels and our approach. There were a few comments that although we have quite an open process, we could do a better job of communicating the project.
In terms of format, we seemed to settle on something with a partial presentation (less than 30mins) followed by open Q&A. Sourcing questions would also allow us to put together an FAQ and become more aware of — and deal with — the common issues that crop up. It might even be worth asking around directly for what people would like to get out of the session and go from there. Amir will look into this and will bring up some ideas in about a month (i.e. in the call after the next one).
--
Amir apologises for the recurring delays in getting the call notes up.
Hannes has more thoughts to share on security things. Will post to the list.
The next call is scheduled for Wednesday, 22nd April, though we may have to shift to the Thursday again. 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.