[Xen-API] RE: [Xen-devel] release of 'xapi' toolstack

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

Hi,

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:

  http://www.xen.org/files/XenCloud/ocamldoc/

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
  xc: hypercalls

xen-api.hg: most of the stuff is here
  java: contains the example Java VM console viewer
  javascript: contains the example Javascript UI
  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 :)

Cheers,
Dave

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api