Re: [Xen-API] Xapi Project 2.0 release

[George Shuklin <george.shuklin@xxxxxxxxx>]

On 06/03/2014 11:25 AM, Jon Ludlam wrote:
> > > Yes, building the ISO was and still is awkward for non-Citrix people.
> > > This isn't a release of the ISO though, this is just a release of some
> > > of the tools on the ISO, and the biggest focus is on making it work
> > > _properly_ outside the context of XenServer. As Dave mentioned,
> > > buildroot is proof that the source can work in both a Debian-like and
> > > CentOS-like environment.
> > All problems with xapi and Xenserver is that XenServer is 'tightly
> > build' bunch of scripts and patched programs, outside of xapi. If you
> > looks to execution path for real operations with VMs, you can see,
> > that right after nice and cool ocaml code in xapi, there is an
> > extremely strange code on python ( os.popen('ls') for the file list is
> > strong example of 'strange'). But right after python code
> > (/opt/xensource/sm) there is much much more problematic set of shell
> > scripts for many host-wide operations (/opt/xensource/scripts).
> >
> > It is not core part and it was very poorly maintained outside
> > XenServer. I filed more than 10 bugs of completely broken functions
> > (like host rename) - they are clearly no 'xapi', but xapi without them
> > is cripple.
> >
> > if this has been changed, it really nice. I really hope so.
> This is interesting. We've been working under the assumption that bits
> of the API just won't work when you're not in a XenServer context - for
> example, the patch management APIs - they just wouldn't make sense.
> However, the VM, storage and most of the networking APIs are intended to
> be first class and should work correctly. Then there's a grey area where
> it's not clear whether people will expect things to work or not - host
> rename is a good example. Should it work?
Last time I saw xapi outside XenServer, it did not work. As well, as 
most of host-specific things.
As I say, main problem is that xapi is very pure and strict inside and 
require same strictness from running environment. There is no 
'discovery', no 'adaptation' , no 'correction'. If environment does not 
match xapi expectation, everything is wrong. And xapi will not take 
(mostly) attempts to fix it.
Hostname, network settings for management network, iscsi error recovery 
- all that is isolated by rather thick layer of shell scripts without 
any agility it it.
It sound like bulling the poor xapi, but I've got rather painfull 
experience with production under high load, and there is many dark IO 
corners around glorious api model.
Simple examples: if iscsi drive change it name due logon/logoff, there 
is no way to reconnect everything back without host reboot. If remove 
host has no enough memory to accept VM and migration starts (and fails), 
VM will leave in broken state. If vm dies unexpectedly during shutdown 
initiation, tapdisk will leave VDI locked endlessly (with actual opened 
fd and running tapdisk process, without corresponding domain).
List is very, very, very large. Most of it has no relation to API, but 
caused by misscommunication between xen, linux drivers, udev and shell 
scripts managing them.
> Buildroot is just example packaging configuration. The tests are from
> OpenStack, and are tests for the functionality OpenStack wants.
Oh, ok. Is it cover all python scripts for storage management?
> > I don't want to be rude, but xapi is too  'api-centric' and just
> > ignore all 'dirty' (in CS meaning of 'dirty') operations like disk
> > initialization, volume manipulation and so on. And it passes all those
> > operations to 'dirty' languages like python and bash to handle dirty
> > work. And they do it dirty (pun intended).
> Which isn't entirely unreasonable - it at least gives an opportunity to
> make quick 'dirty' fixes when the environment has changed.
>
> You're dead right that XenServer is, and has always been, a 'tightly
> coupled' system. It's an embedded system, and that's the mindset; it has
> always had complete control of the system. However, it would be a
> mistake to try and make that work in a general linux environment. The
> bits I would like to see work are the sorts of things that Xen
> Orchestra, CloudStack, OpenStack, Vagrant,  & co all want to do -
> install, start & stop VMs, configure their networking, snapshot their
> disks, migrate and so on. Part of that is indeed fixing things like the
> network and storage scripts so that they are more tolerant and careful,
> and there is definitely work to do on that front. We've got a start, for
> example 'ffs', a storage backend that is much easier to run on an
> already-installed system, but there's still plenty of work to do. The
> intention here is first to make the master branches at least work, so
> that any work to make them work _well_ can be easily upstreamed.
One more important notice. Xapi is really RPC hungry. In large 
installation it cause serious CPU load on master just to control all 
slaves and almost nothing can happens without master approval. And xapi 
is kinda 'commander and worker' same time.
But most of cloud orchestration do not want too smart host control 
software. xapi is just too big and complicated compare to libvirtd/qemu 
(just example). I think, for purposes of underlaying 
host-hypervisor-management software xapi should gave up some of it 
abstraction and complexity toward the simplicity. For example, for 
openstack all sm code is just source of headaches (espesially with 
randomly changing relationship between vdi uuid, files and attached 
drives to virtual machine during snapshot manipulation). Same for 
HA-stuff. Openstack do not need 'highly available pool master'. It does 
not need even the master of the pool. Same for all smart stuff around 
VPP, templating and so on.
I think that overcomplicated part cause problems for 'short path' and 
one of the reasons xapi is not loved by openstack/qemu community.

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api