[Xen-API] Observations and opinions from the 2nd phonecall

[Ian Blenke <iblenke@xxxxxxxxxx>]

It was mentioned that Citrix may have an internal interest in bringing the OpenSource XenAPI in to sync with their current commercial offering.

- Can we get some kind of commitment from Citrix to this end?
- Should we be trying to follow the commercial XenAPI direction either way?
- Any commercial third party apps, or customer written management harnesses, written against the commercial XenAPI could conceivably be used against the OpenSource XenAPI in this case.

It was also mentioned that there is a pluggable storage backend to the commercial XenAPI for mapping UUIDs to actual storage elements.
- Should we be trying to augment the XenAPI to do something beyond UUID vdi mapping?
- Would it be better to define a XenAPI “backend” SPI layer for plugins to be written in a implementation specific way?

It appears to me that the opensource XenAPI really needs to be a bit more flexible than the Citrix commercial product offering. The Citrix commercial offering has a cluster aware management layer behind their XenAPI. Clustered storage and networking is managed behind the scenes, abstracted out of view.

The opensource XenAPI implementation has no such layer, it was intended to manage one dom0 node at a time, independently.

After the call, it seems like everyone likes the idea of a pluggable backend. In this case, the XenAPI becomes more of a middleware layer of sorts, providing a unified API frontend and a pluggable “SPI” backend to graft onto whatever management harness a user should decide to use.

This is the approach the libvirt project has taken, with any number of virtual backends available for the API frontend (qemu, kvm, etc, etc). The downside to trying to be everything to everyone, however, is that you’re stuck with a least-common-denominator approach.

The opensource Xen project as a whole seems to have generally avoided the need for a single management harness to date. This appears to have been delegated purely to commercial offerings.
That has led to a gamut of turn-key commercial offerings that seem to completely disregard integrating with the opensource Xen project based servers generally based on licensing models.

I’m ok with commercial offerings like Xen Enterprise/Server, Virtual Iron,  xVM Ops Center 2.0, Hyperic, etc, users need vendor supported product offerings.

OTOH, it sure would be nice to see OpenQRM, ZenOSS, zentific, xengine, and other opensource based engines easily integrate and manage opensource Xen based servers regardless of distribution and packaging.

So I guess the question I’m asking here is: how can we make XenAPI something that can support a pluggable backend to encourage opensource management harnesses to be written?

• Ian C. Blenke <iblenke@xxxxxxxxxx> <ian@xxxxxxxxxx> http://ian.blenke.com/

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