23th April 2013: Irminsule, concurrent revisions and release checklist
Attendees: Anil Madhavapeddy, Dave Scott, Vincent Bernardoff, Thomas Gazagnaire, Richard Mortier, Daniel Bünzli, Prashanth Mundkur.
We managed to get screen-sharing working from Dave's iPad, with pinch-to-zoom maxing the screen-size and everyone realising that we are living in the future! Thomas walked us through the Irminsule interfaces, available on Github. Irminsule has three parts, discussed in more detail below: a low-level immutable collection of binary blobs, some structured objects and revision-branching structure.
When you write a value, you get a key (SHA1 or SHA256?). You can read the value with a key, if you don't have a key you get a null. This is non-blocking.
On top of immutable DB you have some structured objects, like trees. If you give a root and hash, it'll give you back some key.
Anil: how come the
merge function maps a
value and not
Conversation discussing the type of the
merge function, and how higher level
abstractions could be built on top of it. More design work needed to ensure
that existing git merge strategies can be implemented using it.
Anil: Can Irminsule replace Xenstore with a persistent version? Consensus is this should be easy once Dave finishes his xenstore refactoring to isolate the database, and careful encoding of existing transaction semantics into Irminsule (which Thomas is familiar with as he did lots of work on Xenstore). Dave Scott agrees with this assessment and thinks a distributed xenstore isnt too bad.
Prashanth: What about traversal order in the tree? would it make sense to have specified order of traversal? Answer: there is a stable order, but in the future we may want to define iterators instead of creating lots of temporary list. This is just an allocation optimisation and not important for version 1.
On top of structured objects, you have a revision structure. Read Git from the Bottom Up for a design perspective on this. Tags are the only mutable structure, and annotated tags create objects with tags associated with them. Thomas started to work on (only two days) how to sync between two repositories via a pull/push model, and begin to model existing concurrency models on top of the branch-consistent model exposed by Irminsule.
Anil: How do you construct a remote node? Thomas: right now the module types are kept abstract deliberately, but the implementation provides a constructor function (e.g. TCP).
Anil: Sounds like this almost ready for David Sheets to pick up and have a look at for OCamlot. We only need basic stuff for OCamlot and could build simple queues on top of this. Is persistence like the git file format? Thomas: yes, see samoht/cagit for the pure-OCaml git library.
Prashanth: What is the list of labels in the TREE.set function for? Answer: the label list is the list of path fragments in the DAG, analogous to a filename under UNIX.
Anil: points out a typo in the
let in TG's code. The world breaths a sigh of relief.
Mort spoke about froctal, which is a wrapper to track configuration dependencies in Mirage code. See his README for thoughts so far. He first looked at ocaml-md which was toy experiment last summer to track reconfiguration and then tried Jake Donham's Froc library during ASPLOS. Then he was thinking about what we could use FRP for in Mirage. Self-scaling web services doesn't necessarily seem to need FRP, but just simpler configuration tracking instead.
Anil: There's a healthy followup list of papers, specifically from MSR on Concurrent Revisions. The cloud types even provide automatic reconciliation, and so are a good fit for the Irminsule model.
Mort then described the beginnings of an attempt of implementation of concurrent revisions, with alternate versions using modules and objects (which are closer to the original pseudocode in the paper), but is running into the hard bits of classes in OCaml. General sounds of sympathy from the group, and advice that classes aren't necessary for many uses of objects in OCaml, and that straightforward object definitions and polymorphism might be easier instead.
Around 53 libraries in three states, with more coming in fast:
Anil: Note that some OCL people are working on improvements to tooling around documentation, such as opam-doc. Should go though list of libs and define what will get done. See the dev preview checklist on the wiki for more information on progress.
Mort: Does anyone else have issues with tuntap on Linux? Turns out no-one else has really tried as most of us use Tuntap on MacOS X and the Xen backend on Linux. Vincent's ocaml-tuntap tests should be sufficient to try a unit test though.