and developer guides
Amir Chaudhry (chair), Thomas Gazagnaire, Wassim Haddad, Thomas Leonard, Jon Ludlam, Anil Madhavapeddy, Hannes Menhert, Richard (Mort) Mortier, Mindy Preston, Dave Scott and Jeremy Yallop
We've had some recent issues with MirageOS website uptime (see mirage/mirage-www#404 — the issue number is quite ironic). Part of the problem in debugging this is that we don't have adequate log capturing yet. We could put the site in auto-restart mode but it's much better to know that it's down and work towards a fix (rather than relying too heavily on restarts).
One approach is to rewrite
xenconsoled to have more flexibility to output
logs. We could turn this into a Pioneer Project. Mort can write up a
short paragraph and Anil/Dave/ThomasG can be mentor(s). There may even be
existing patches out there that we could try now but it's actually quite
tricky to recompile these without crashing the machine. Any help from others
would be appreciated.
Another one of the required pieces is a reporter for logs. ThomasL wrote one and will send an email to the list with information on the issues he came across.
Jeremy has been looking over this carefully, comparing with things in
mirage-dev, and fixing some xen-related issues. This is still ongoing and
it's just a lot of little things that need cleaning up e.g. console connects
to xenstore, so it's a little bit different. The unix aspects have been
checked over carefully but we're also checking that the xen pieces are also ok.
Jeremy will try and post updates on how things are going. The release gate
for Functoria might be when
mirage-www runs with a dynamic block device
using functoria (that should stress everything).
JonL tried functoria stuff and had a few issues but it wasn't clear if this
was due to functoria or some other issue with Opam. Will delete
try again. ThomasL also tried functoria and it worked well but on Qubes (his
primary OS), there were some issues as it makes assumptions.
Charrua — There's still a pending blog post which should be ready to merge.
The related code for
mirage-skeleton has already been reviewed and merged
and the last step is to check the blog post one last time (it's already been
reviewed by others).
Sidenote: At the moment no-one has had a chance to look at making a DHCP client with Charrua. It would be good if someone could work towards this and perhaps we could make it a Pioneer Project, but it would likely be a 5-star one.
Irmin update - There have been a lot of Irmin releases since the introductory blog post and it would be good to get a follow up post about the progress that's been made. Given the amount of work underway, it's not likely that ThomasG will be able to write this. He'd like to explain what the summer interns did and also document the language bindings that exist — getting all this in one post would be quite lengthy. He'll try to find some time to put thoughts down. Perhaps we can encourage those who wrote the language bindings to write things up.
Since there are likely to be a number of Irmin-related posts, we can set up a short schedule of posts (as we've done before) — can aim to do this around January or February. There doesn't need to be any big fanfare about this, just a mechanism to help get the posts out. For example, surfacing details on how to upgrade from v0.9 to v0.10 would be a useful post.
MirageOS end-of-year review — We've done this previously for 2014 and it was well received, so we should continue the pattern. We have a lot of material to draw on, in terms of changelogs, blog posts and these call notes. Jeremy agreed to take a look at this and see what he can start pulling together for others to look over.
Unikernel.org — There's also a new community site for unikernels as a whole at unikernel.org. Having a short post here to introduce that would be useful and Amir will put something together before the next call. Others are welcome to discuss or comment via mirage-www#412.
ThomasL has been running some MirageOS VMs on Qubes OS (which is his main work environment). He's working on a library to provide support for this (talex5/mirage-qubes), which does enough help the user do something useful.
ThomasL would like to implement a MirageOS firewall VM to replace the existing firewall in Qubes OS. In order to do this, he needs to implement netback support. Dave has a branch somewhere that may help with that and will look at merging it into a current repo. Joanna (Qubes OS project lead), was also asking on Twitter about running a GPG backend as a MirageOS unikernel. It wasn't clear how much additional work would be needed over the existing TLS efforts. Hannes pointed out that there could be quite a bit of work depending on what exactly is required. Help is welcome and there's a thread on the mailing list — "MirageOS AppVMs on Qubes"
There was a question on the list from Wassim about getting back to very small unikernels. Wassim is doing a project on MirageOS and running on a very low memory budget (on x86). Hence any reduction will make a big impact on his use case. The focus is a DHCP server on Xen and they need to reduce the size as they're linking it with other components. He was wondering what the runtime size was for the MirageOS DNS app. It seems that used to be below 8MB but trying to make it any smaller was tricky just due to how Xen. Wassim would be overjoyed if he can get his runtime size down to such levels.
Anil pointed out that the upcoming 'flambda' patch to the OCaml compiler will improve things for all OCaml code. Perhaps we can look again at memory usage when we do our DHCP server using Charrua. Making this runtime small is important for MirageOS too as, we want to deploy to ARM devices.
Wassim will make an issue on the mirage/mirage issue tracker so that we follow up with this.
We ended up discussing two separate types of events, a unikernel 'install party' (like the Linux install parties of yore) and a longer MirageOS hackathon/retreat/dev-meeting.
Unikernel install party — There seems to be desire amongst people to explore some of the other unikernel implementations that are available, e.g. HaLVM, Rump Kernel, IncludeOS, etc. However, getting started with any of these can be non-trival as the getting the environment set up appropriately takes prior knowledge. We thought about arranging the equivalent of an 'install party' (perhaps a 'Hello World!' party?), so that people can get going quickly with a number of different implementations. We'd likely find many ways to improve the onboarding experience for all the implementations. Perhaps we could link this up with the London Unikernel Meetup? Mid-February might be a good time to do this as a one-day/evening event and we could set the scope to be quite broad (and thus invite a lot more people).
MirageOS hackathon — There is also desire to hold an OpenBSD-style hackathon purely for MirageOS. This would be an event over several days, with the emphasis on writing code and working towards some goals (to be defined at the beginning of the event). Ideally, this would be held at some other location where people would travel to. This event could be arranged to take place in March/April to give people enough time to plan.
Since both events are serving different needs, there's no reason we couldn't do both. It's mostly a matter of organising and ensuring that there would be enough participants for both.
1 star projects — In the run up to the holidays, it would be great if we can gather a few more 1-star Pioneer Projects. This will help anyone who's thinking of getting started with MirageOS over the break, even if they don't contact anyone directly. It would also be timely to review the star-ratings for the current projects. On the next call, it would be good to review the project list to see where things stand.
Outreachy — One student will be working on NTP, which will have benefits to a number of other projects. Hannes is mentor and Mort can provide advice on what he had to do as a mentor from last time — the reporting requirements seem to be quite lightweight.
Longer projects — There was also the suggestion of more 'elastic' projects. These would be areas that start off easy and small but can expand and become more substantive pieces of work (e.g. can last for 3 months). Performance regression testing is one such area. Projects like this would also help onboard new contributors over an extended period.
conduit — JonL can pick up
vchan again. ThomasL is using it
for Qubes and Mindy has a number of uses for it. Wassim is also using it so
improvements are welcome (it's a critical piece of their stack). Wassim's aim
is to use
conduit but docs are quite sparse and any links to more would be
useful. Anil has blog post somewhere that he can link to.