[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Pioneer project propositions

  • To: Anil Madhavapeddy <anil@xxxxxxxxxx>
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Tue, 16 Aug 2016 15:05:44 +0200
  • Cc: "mirageos-devel@xxxxxxxxxxxxxxxxxxxx" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 16 Aug 2016 13:05:57 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:cc:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=FaxOGjKx3VF6+AodJi9QuyUAa7Wdu7Ko7zH0Cs9imSmI/ANchHx0KUP8ozNsvhg49V3z5C8YlPQo T0A+XVueJN4tmGyK8tmUQth+ag5YZ+gCOkcdhaTsgrp08UYUr9H2
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

Thanks! I'm happy to mentor these initially, once we drill down what they mean 

Unikernel galery (initial idea by mort)

By combining functoria and js_of_ocaml, it should be possible to make a webpage 
that showcase a set of unikernels (for example, mirage-skeleton). We could then 
go further and allow to run functoria in the webpage directly (showing dots and 
description, and so on).

This project would involved several tasks: First, understand how functoria works (and 
modify it if necessary). Then, become familiar with js_of_ocaml and be able to make a 
pretty webpage with it. Finally, improve visualisation and documentation informations 
that are available through "mirage describe" (and the --dot option) and adapt 
them to a web format.
This one's extremely interesting, but could be broken down a little more before it 
becomes a pioneer project.  As I understand it, the "gallery" is not referring 
to possible unikernel applications, but instead to exposing the dependency chain of any 
application as a web page.
The dependency chain and all the other various informations (keys, opam/ocamlfind dependencies, ...). Terminals is a very limited environment to expose informations, we could show them much better in HTML. The first step would be something static.

So this would concretely involve compiling the functoria config file into 
JavaScript and executing it with a UI.  Would an intermediate (and easier) 
project be to build an interactive tty/console application that would render 
the various choices as textual dialogs, and then lift the whole lot into JS?  
That would let `mirage describe` be a bit more like `make menuconfig` in a 
Linux kernel compilation.
For the first step, I don't really see it as compiling as much as "dumping all the unikernel informations". functoria always build all the static knowledge given by a config.ml before evaluation (which is what you see if you do "mirage describe (--dot)" without any key and without --eval). That knowledge can be exported to javascript, similarly to the app_info device. The task you propose seems related, but orthogonal. However, your proposition is really cool too, I like it very much, and I think it would actually be reasonably easy! All the tools to do incremental evaluation are there, so it just needs a UI.

High level devices

A good amount of the mirage devices that are implemented right now (in 
mirage.ml) are fairly low level. Even the one related to web servers need a 
rather large amount of boilerplate to setup (see the static_website_tls 
unikernel in mirage-skeleton). The mirage-seal project attempted to improve 
that by providing an external tool that would emit the necessary code. It's 
also well known that using js_of_ocaml in a unikernel is slightly nightmare-ish 
on the build system side.

It should be possible to replace all that by new devices that provide 
everything directly, using judicious functor applications and configure 
scripts. This would involve studying the various idioms that are used (in 
mirage-skeleton, mirage-www and other unikernels) and coming up with an API 
that is flexible enough to cover all the use cases.

I expect this would make it much easier to create new unikernel that do high 
level tasks.
Definitely agree with this one. For Pioneer Projects, how about specific levels:

- Deprecate mirage-seal would be a good one, since it horribly wraps the 
`mirage` CLI and is a very common usecase
- A DNS server would be useful (parse zone files -> Xen kernel)
Yes, the new dns library is not yet device-ified.
- Syslogd device (Gina?)
It should be possible to easily plug that as a replacement log device (talex designed the API for that purpose).

For these, there are some missing device implementations too -- for instance, 
cloning a Git repository as an option to crunch, so that the configuration can 
be handled more gracefully.  Anyone got any other missing devices they'd really 
like to see in the CLI?
As I see it, this would also be the occasion to figure out which API are "easily device-ified". Some APIs are very easy (the whole cohttp stack). Other, less so (the conduit stuff, and I suspect the DNS api will be awkward). It would be interesting to have guidelines for library authors on what is a nice API for Mirage.

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.