On 15 May 2014, at 13:52, Jon Ludlam <jonathan.lud...@eu.citrix.com> wrote:
> On 15/05/14 12:18, Anil Madhavapeddy wrote: >> I'm particularly interested in getting a Xapi instance running as a >> stable package in OPAM. This would make it much easier to experiment >> with the codebase in a VM in particular. Dave and I are mentoring a >> GSoC student on the topic of cloud APIs, but spending most of her time >> on getting Xapi installed wouldn't be productive, hence the desire for >> this. If the OCaml xml-rpc bindings work from OPAM too, that would be >> a very nice place to start. best, Anil > > Agreed, that would be really nice. We had something like this working > before; if you add the xapi-project opam repository it might even still > work. However, I'm not convinced that it was executed in the right way. > The trouble is the set of daemons are all intended to run system-wide, > and getting them to run from within your .opam directory was awkward. > > Is there a best-practices guide for doing this sort of thing? Should we > be only using opam to install the libraries, and something else for > installing the daemons & executables? Should we be symlinking rather > than changing the hardcoded paths? Should we try and put as many paths > into config files (difficult when the path is in a library used by > several components)? Good question -- the general guideline here would be to focus either on making Xapi relocatable (so it can run from within ~/.opam), or as a Docker instance (but this blocks usage from NetBSD or FreeBSD when it gets dom0 support). OPAM itself works well for installing either executables or libraries, but it's best to keep it to OCaml code. If importing Xapi wholesale is very difficult, perhaps cutting up portions of it into libraries and pulling them into OPAM individually would help reduce the burden and also allow the independent use of some of the components? In general, this effort should make porting Xapi to different distros easier anyway, since control over paths is essential. Are there many patched system libraries (such as LVM) still needed? > Getting the XenAPI client library working is much easier - in fact, this > bit already works and is in the normal opam repository. I can post a > walkthrough of this if you like? Aha, useful! I'll let Dave comment on whether this would useful for the GSoC project, but I did apply a quick fix to get it building again: (broken log due to missing cstruct.lwt) https://github.com/avsm/opam-bulk-logs/blob/master/20140514/4.01.0/raw/xen-api-client (fix in opam-repository) https://github.com/ocaml/opam-repository/pull/2078 -anil _______________________________________________ Xen-api mailing list Xen-api@lists.xen.org http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
