Several community members have contacted me recently about the Xen-API utilities. I looked into this and discovered a great opportunity for community members looking for a project to contribute to. So, I am announcing a new community effort to complete the development of the Xen-API utilities. If you are interested in working on the Xen-API project please email me at firstname.lastname@example.org and I will call a meeting in mid-May with all people interested to get the project underway.
NOTE – This interface is not to be seen as a replacement for the existing XML-RPC interface and people should not infer anything by this project.
Here are some thoughts on the importance of the Xen-API if you are considering joining this community effort:
- Xen-API cleans up a lot of the cruft of the older APIs
- Authentication aspect to the Xen-API allows the API to be used off-box securely
- Xen-API’s event registration / dispatch piece is much better than the old API, making it much easier to build web GUIs or health monitors
- The Xen-API has two mechanisms, one for synchronous task invocation, and a congruent one for asynchronous tasks. This means, for example, that you can reboot a VM, and either block waiting for it to complete, or get a task handle and poll back later. This gives application developers the freedom to choose how they interact with Xend
- Xend will get a code update from this project and will give developers a chance to learn more about xm as well as Xend (Xend is written in Python)
- Xen-API already has C and Python bindings in the Xen tree; Ruby bindings are also rumored to exist
Available information on Xen-API:
- xen-api mailing list
- WIKI Page: http://wiki.xensource.com/xenwiki/XenApi
- Xen Summit Presentation on Xen-API from April 2007 event
- Xen-API documents in xen-unstable tree at /docs/xen-api (need graphviz installed to make the xen-api Latex document)