RE: RE: [Xen-API] Xen-API: XMLRPC Documentation

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

Hi George,

Thanks for your email -- I couldn't resist replying :-) comments inline below.

> I do not want to be offensive to current XCP developers, but right now
> I
> see few really important problems:

No offence taken!

> 1) Some parts of XCP is still closed source (HA, WLB) and XCP heavy
> depends on them. Most worst is that WLB from Citrix created for windows
> and depends on MSSQL (I think, we shall not expect Microsoft to publish
> MSSQL source code under GPL within next 5 months).

It's true that the HA heartbeat daemon and the windows WLB service are not 
open-source. However it's possible to replace these components-- xapi 
communicates with them both through fairly simple XML-based interfaces.

Alternatively you could take an approach like that of XCCS-- I believe it has a 
load-balancing system based entirely upon the xe CLI.
 
> 2) Ocaml. May be cool academic language, but I think, there is a very
> few ocaml programmers and intersection of sets of ocaml programmers and
> xen specialists tends to single numbers.

I believe the intersection of ocaml programmers and xen specialists is fairly 
small. In fact when I first started working on xapi I didn't know anything 
about xen so I wasn't in the intersection either. IIRC it took me at least a 
month or two to figure out the basics of xen... maybe someone else on the list 
can comment on how long it took them to learn ocaml? :)

Interestingly we wrote up some of our experiences with ocaml and xen in this 
experience paper which we're going to present at ICFP (intl conf on functional 
programming).

http://anil.recoil.org/papers/2010-icfp-xen.pdf
 
> 3) Not very cute internal architecture of xapi. Database are kept in
> plaintext format (just ocaml serialisation), intensive cross-syncing
> (lot of empty pool updates via XenAPI notification system), not very
> cute architecture (master and slave, all slaves are kept database, but
> only master will reply to requests).

The database is serialized in XML format but the primary copy is kept in memory 
on the pool master. The copies sent to the slaves are just backups. The master 
is authoritative for the pool metadata.

I think that the best choice of architecture depends entirely on the proposed 
users and usage scenarios. What do you think? What sort of scenarios and 
architectures are you thinking of?

> 4) Lack of full access to domain internals (XS, XC interfaces). Domains
> have pool-wide options and 'local' options (from xc point of view). We
> have no method to set up some XS values to keep them between migration.

This is interesting -- could you explain more what you are trying to do? For 
stuff like calling libxc functions, I recommend adding flags to the 
VM.platform/ map, which gets written to xenstore, and then picking them up in 
the 'xenguest' binary (mostly written in C)
 
> 5) Scrapyard within other-config field (it contains some critical for
> VM
> values to run (install-repository), but it all joined in some kind of
> blob "dig it out yourself").

The other-config (string -> string) map is intended for "extra" data which 
isn't part of the full API. It's good for making things work quickly and 
experimenting... the idea is that, once we are happy with an approach, we can 
make "first-class" API fields for the data. The danger is of adding things to 
the API too quickly.. because then you are left with a backwards-compat legacy 
problem IYSWIM.

> 6) Very delicate and troublefull xapi toolstack build process.

This certainly could be improved!

> 7) Lack of 'change startup config while VM running' (i'm about values,
> which one have meaning while vm is starting: VCPUs-at-startup,
> memory-static-*, etc - you can change them only while VM is offline;
> more reasonably implementation must allow to change those values while
> VM is online, but accept them to work at reboot/shutdown/start).

This was actually changed relatively recently for two reasons (which you may 
disagree with!):
1. it simplifies the presentation in the user interface
2. it makes it easier to tightly control the amount of memory in use by a 
domain, which is essential for controlling ballooning on the host/
 
> 8) Heavy limitation on pool size (I still not test it myself, but I
> hear, limitation is 16 hosts per pool - that is not good for normal
> cloud with many hosts).

There is no pool size limit. However we focus most of our testing on 16 host 
pools. Interestingly, I'm currently working on a bug which manifests on pools 
with 30+ hosts.

Although, it depends on what you mean by "many". The xapi pool is really the 
"unit of shared storage"; if you have a much larger setup then I'd recommend 
making some kind of higher-level interface.

> 9) Unavailability for using external kernels for PV.

Could you explain this one more?

> 10) Heavy depends on guest tools.

I think this could probably be changed fairly easily.

> Last four is problem of XCP, not xapi, but firsts are problems of xapi.
> 
> One more problem is XenAPI by itself: one connection per one operation
> is TOO heavy to use as fast basis for future development. (I think, it
> needs for some kind of interaction without connectivity lost after each
> command).

I don't understand... xapi does support HTTP/1.1 with persistent connections-- 
do you mean something different?


Cheers,
Dave

> (But I personally think, ocaml is main difficulty for community
> development - threshold of entry is too high for most intersted in
> development).
> 
> (F.e. I glad to write few more classes for vm_metrics - I know C and
> Python, but I can not even read ocaml code).
> 
> Ð ÐÑÐ, 26/08/2010 Ð 14:17 -0700, yueyu.lin ÐÐÑÐÑ:
> > Thanks a lot. It helps me a lot.
> > Yes indeed, we need to make the documentations better to attract more
> > developers to develop platforms and applications based on Xen-Cloud.
> >
> >
> > Actually I'm a little bit curious how the host side implemented, in
> > user space or kernel space, although it's beyond my current
> > understanding over Xen and XCP
> >
> > On Aug 26, 2010, at 05:06 AM, Rob Hoes <Rob.Hoes@xxxxxxxxxx> wrote:
> >
> >
> > > Hi Yueyu,
> > >
> > > There is a PDF document containing more details of the XML-RPC
> > > protocol. Unfortunately I cannot find an XCP-specific version
> > > online, but it is more or less the same as the XenServer API
> > > reference, which you can find at
> > > http://support.citrix.com/servlet/KbServlet/download/23833-102-
> 646000/xenenterpriseapi.pdf. See Chapter 1 for the details of how to
> use the XML-RPC protocol.
> > >
> > > Then, you can use http://www.xen.org/files/XenCloud/ocamldoc/ as a
> > > reference for the API's classes, calls etc. This is totally
> > > independent of any programming language.
> > >
> > > We should probably integrate the information of Chapter 1 of the
> PDF
> > > in the HTML docs, and also put the PDF online...
> > >
> > > Regards,
> > > Rob
> > >
> > > -----Original Message-----
> > > From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
> > > [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of George
> > > Shuklin
> > > Sent: 26 August 2010 12:57
> > > To: xen-api@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-API] Xen-API: XMLRPC Documentation
> > >
> > > Yes, you can ignore ocaml existence in first iteration (see below)
> > > and
> > > use (for example) python with XenAPI.py interface. Main difference
> > > in
> > > xapi and xend implementation of XenAPI is pool-related classed
> (xend
> > > have no conception of pool).
> > >
> > > About ocaml... In first XenAPI is language-neutral interface, but
> > > xapi
> > > implementation is poor: they store some values in ocaml format (f.e.
> > > last_boot_record for vm). But management part and main data are
> > > available for use without ocaml concern
> > >
> > > Documentation published on xen.org site:
> > > http://www.xen.org/files/XenCloud/ocamldoc/
> > >
> > > Yes, this is only reference. No guideline or tutorial available.
> > >
> > > Ð ÐÑÐ, 26/08/2010 Ð 04:29 -0700, Yueyu Lin ÐÐÑÐÑ:
> > > > Hi, all
> > > > I have done some research over the interfaces of Xen(XCP). I
> found
> > > this page to introduce the history of API:
> > > http://wiki.xensource.com/xenwiki/API_History
> > > > If I understand correctly, both xend and xapi have implemented
> the
> > > server side(host side) service. The client side(management tools)
> > > just sends the XML-RPC requests to either xend or xapi.
> > > > My question is : I can only find xapi documentation describes the
> > > API in Ocaml way. I have no clue how to compose the XML-RPC and get
> > > the response. If my understanding is correct, I don't
> > > > need to learn ocaml to use xapi since I only need to send XML-RPC
> > > requests to host that means I can use every language I like.
> > > > I think if the xend and xapi need to implement the service, they
> > > should have the XML-RPC documentation first. Can someone point me
> > > the location of the whole XML-RPC documentation so that
> > > > I can write my own client program to access and manage the XCP
> > > hosts.
> > > > Thanks a lot!
> > > >
> > > > _______________________________________________
> > > > xen-api mailing list
> > > > xen-api@xxxxxxxxxxxxxxxxxx
> > > > http://lists.xensource.com/mailman/listinfo/xen-api
> > >
> > >
> > >
> > > _______________________________________________
> > > xen-api mailing list
> > > xen-api@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/mailman/listinfo/xen-api
> > >
> > > _______________________________________________
> > > xen-api mailing list
> > > xen-api@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/mailman/listinfo/xen-api
> > >
> 
> 
> 
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api

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