and developer guides
Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, Thomas Leonard, Jon Ludlam, Anil Madhavapeddy, Richard Mortier and Dave Scott.
Anil is in Chicago at the annual Xen Developer Summit speaking about Mirage 2.0 and branch consistency for Xen Stub Domains (abstract). Some feedback from the talk was emailed to the list and is summarised here (see the thread for discussion).
Git workflow very popular. Lots of people twigged onto the maintainability
benefits of git bisect
automation in particular.
Questions about why Xenstore transactions are still necessary in the modern world. Can replace with consensus protocols instead? Maybe time for an ABI bump to deprecate the ancient xenstore protocol.
Space usage is a concern — building an RRD-style constant size library to maintain progressive history would be a big win.
Excellent talk from Felipe Huici from NEC about building much denser VM workloads, and he observed that Xenstored/xenconsoled are a big bottleneck at ~10000 VMs (slides). Some sub notes:
In general, it was very positive and there was lots of interest in Irmin. Some feedback from attendees is that some more structure around Mirage would help people who want to contribute. Right now there are libraries everywhere and it's difficult to see where you can get involved without having to understand everything. Making a framework around the upcoming headline features would be especially useful. This would be something like a roadmap for Mirage 3.0. Overall, we should be aiming to get better at this kind of thing with every release (and for the most part, we seem to be — feedback is always welcome!).
Got HTTP request working through Mirage. Requires DNS and TCP set up and the like. It's quite a big patch set, which touches a number of libraries and a number of things are not backward compatible. Hence these need to be co-ordinated and there's an issue to track this (mirage/mirage#287). Dave will add vchan support when ready. This is an important set of patches and we will get a working transport layer. The updates to mirage-skeleton are minor and also tracked in the issue.
ThomasG investigating how he could remove the core_kernel
dependency
and is also cleaning up
Benjamin Farinier's queues
and ropes
work to port that in.
Bug reports are coming in from early users and one of the
main points is that we should improve the user side of things.
ThomasL trying to get profiling data out of ARM, with the intent of producing some fun and useful graphs to share.
Anil previously mentioned getting ethernet at 100MB. Seems we can get 18MB over UDP at the moment and Linux only manages 13MB. TCP on Mirage is 11MB and Linux gets 40MB. Not really clear what these difference are due to. Also tried to dump from console but turned out to be Xen that was rate limiting things. Anil suggested that Thomas check that the free slots in rings are being fully utilised.
It would be really useful if opam can make the profiling process easier. A compiler switch could help with this and ThomasG can look into that (for native, not bytecode).
When this is done, ThomasL will write it all up with lots of pretty graphs.
Amir has some fairly basic questions about Xen, Mirage and ARM. Specifically, what the differences are between Xen on the cloud (x86) and embedded devices (ARM). Others tell him this mainly relates to Mini-OS and it's relation to Mirage (and ClickOS and HaLVM etc). There are several posts that might help explain things, for example ThomasL's blog post on ARM and wiki pages on Xen events and setting up a Cubieboard2. Amir will start with those and if anything isn't clear, he'll ask ThomasG about it. Amir might write this up for the website if it'll help explain to others too.
[edit: This is proof that there's no such thing as a stupid question - AC]
ARM features: New stuff coming. Next version of Xen might take advantage of this so we should think about this in time.
Some of the packages in the Xapi opam remote are ready to go upstream. Largely because Dave got them in shape recently.
We had another hiccup with the call today and we need to fix this. Proposal is that we sort out a GoToMeeting account such that more than one person can start the call. GTM is better than Google Hangouts as it allows for people to dial in by phone (very useful when travelling or on poor wifi).
Next call is scheduled for 2nd September - Please refer to the mailing list for actual details a day or so in advance.