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@lists.xen.org
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
