Re: [MirageOS-devel] Pioneer project propositions

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 12 Aug 2016, at 14:37, Drup <drupyog+caml@xxxxxxxx> wrote:
> 
> Hi,
> 
> I wanted to propose two new pioneer projects. Given that I can't Mentor 
> myself, I prefer to send an email here than to add it directly to the wiki. 
> I've left out the difficulty ratting, because I have literally no idea. I 
> will gladly help potential mentees (and I review everything functoria-related 
> anyway).

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. 

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.

> 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)
- Syslogd device (Gina?)

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?

Anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel