[Xen-API] RE: [Xen-devel] release of 'xapi' toolstack
Mark Johnson wrote:
> This is great that Citrix is open sourcing this code... Thanks for that!
> Some questions...
> o Are there any high level READMEs for what is in what directories
> for the two repos?
The best we've got at the moment is some generated module/function-level docs:
Here's a quick inline summary:
xen-dist-ocaml.hg: a bunch of Makefiles (in the style of BSD ports I think) for
downloading and building external tools and libs. At some point we should
probably switch to using RPMS.
xen-api-libs.hg: utility libraries, some xen-specific some more general: eg
camldm: interface to device-mapper
cdrom: wrappers around CDROM-specific ioctls
eventchn: xen event channel stubs
fake: used as part of a hypercall simulator (for testing)
log: logging library (with syslog bindings)
mmap: interface to mmap
rpc-light: a simple RPC framework capable of using XMLRPC and JSON
sha1: stubs for generating sha1sums
stdext: helper functions to augment standard libraries
uuid: generates uuids
xb: stuff for talking xenbus
xs: stuff for talking to xenstore
xen-api.hg: most of the stuff is here
java: contains the example Java VM console viewer
ocaml/auth: stuff for PAM, AD
ocaml/client_records: utility stuff for the CLI
ocaml/console: console forwarding
ocaml/database: manages the VM, host metadata
ocaml/idl/datamodel.ml: defines the API
ocaml/xenops: low-level domain, qemu management
ocaml/xapi/xapi_*: high-level API entrypoints
ocaml/xapi/vmops: higher-level domain, qemu management
ocaml/xenstored: ocaml xenstore
> o What has not been open sourced? i.e. after a brief look, I didn't
> see the VHD code... But I could have missed it...
My understanding is that the VHD code was OSSed a while back. Although we're
still on blktap1, we're intending to explicitly switch to the new blktap2 stuff
as soon as practical.
> o Now that there are two tool stacks, are there any short term
> and long term thoughts, plans, roadmaps, etc...
> o I noticed there are a fair amount of Xen and qemu patches.. I
> see that some are toolset specific and some are not.. Are there any
> plans to start rolling these into unstable and a a few of them into 3.4?
> (I realize this takes a lot of work and time).
I'm compiling a xapi toolstack architecture document which contains some of our
thoughts on how the toolstack could evolve. It's partially complete (perhaps
such things are always partially complete) but I'll check it into the
xen-api.hg repo anyway. We also have a draft of a toolstack roadmap which I'll
try to get on the wiki.
We're keen to reduce the size of the patch queues. I believe bugfixes are all
upstream but there's still stuff like the occasional backport... or an
interface change that was never upstreamed. For example I think there's a
change to the block device shutdown protocol which makes toolstack error
handling easier. Hopefully we can start discussing those changes and either
drop them or upstream them :)
xen-api mailing list