Re: Mirari, the tool you've all been waiting for!

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 10 Feb 2013, at 19:06, Anil Madhavapeddy wrote:

> ...
> So Thomas and I have been hacking on Mirari, which takes a single 
> configuration file and splits the lifecycle of a Mirage application into 
> three distinct segments:

cool! about to start trying it as i type :)

> * configuration: it scans the config file, checks for any missing OPAM 
> packages, and installs them if missing.  It also looks for any filesystem 
> directives and calls mir-crunch to generate the static ML files.  All of this 
> is glued together into an autogenerated main.ml which is the entry point for 
> the application.
> 
> * build: it runs the OCaml build (via Vincent's obuild), and then issues any 
> backend-specific commands (such as the Xen link, ocamlclean, or whatever else 
> we dream up).
> 
> * run: this is yet to be implemented, and the reason for this mail.  Running 
> a Mirage application is quite stateful: in the case of Xen, we want to 
> monitor the kernel, attach a console, and so on.  Similarly for UNIX, one can 
> imagine the socket version opening up a control channel for Mirari to listen 
> on.  An in the kFreeBSD backend, this would be done via ioctls or other 
> kernel/user interfaces.

one very quick request - don't wait to get it documented and released. i think 
it will still be *significantly* useful in terms of helping build community 
(excuse the pun) and getting others engaged before "mirari run" works. arguably 
for asplos the main things that need to work are understanding how to 
configure, build and run unix and xen targets (bonus marks for "unix socket" vs 
"unix mirage" or whatever we call them now) -- and it's the understanding and 
building bits that require a lot of state and runes at the moment. once i've 
got foo.xen or foo.native, i can run it without too much trouble.

> So I'm going to extend Mirari to add `run` support which is stateful.  Each 
> run will give the application a unique ID, stored locally, and enough 
> information to poll the particular instance.  Every deployment has a 
> different way to track it (Amazon EC2 vs XM vs Xenopsd are all completely 
> different).

this could presumably be extended to include the perf test/experimental harness 
that the asplos paper was crying out for?

> In the longer term, the configuration file format will almost certainly 
> become a DSL to help control the policy a bit better.  We'll design that 
> after we get more experience with building applications like this though.  
> I'm sure Raphael will chime in with "NO FRP!" at this point :-)

and i'll chime in (without evidential basis :) and say "YES FRP" -- presumably 
mirari will itself be a library that could be built into a mirage control vm to 
manage a system of mirages?  

if not, how else are we going to enable skynet to build itself?

-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.