Re: [Xen-API] [Xen-users] New name for Kronos? [was XCP 1.5 availability]

[Todd Deshane <todd.deshane@xxxxxxx>]

At the end of the day XCP, whether in the form of a pre-packaged
appliance distribution or installed on top of a standard Linux
distribution, is more than just Xen + XAPI. It's Xen + XAPI + xe +
Open vSwitch + (anything else needed to make it a great platform). So,
I tend to agree with Wawrzek in that there should be a meta package (a
package that has nothing in it, but depends on everything that should
be installed) called xcp-full (or xcp-system or whatever we decide).

The compromise that the packages are xcp-*, such as xcp-xapi seems OK,
since that is where they came from, but in the long run we need to
think clearly about version compatibility between xcp-xapi and any
other packaged versions of xapi that are being developed (not to imply
that xapi should be fragmented, see below). We really want to avoid
the XenCenter version mismatch issues in the future, especially when
xapi-based systems are being managed by a lot of different interfaces
OpenXenManager, OpenStack, Cloudstack, Zentific, to name a few.

Project Kronos (and that is all it should be - a project code name),
represents a great opportunity for the Xen community and I know that a
lot of people are excited about its future. There are some open
questions, but I think it is likely they will just work themselves out
just like any other open source project.

I think the use cases for xcp-full installed on a Xen dom0 via a
package install on a normal Linux distribution are clear and the
trade-offs have been discussed in some detail [1][2]. The great thing
about having the multiple different choices is one of the really great
thing about Xen. It is also perfectly reasonable for someone to build
an XCP distribution appliance based on Ubuntu or Debian or any other
distro (Citrix may even decide to use a different distro for the basis
of XenServer).

In practice, the xapi package should be the most cutting-edge version
of the API available, followed by xcp-xapi, which in practice will be
(at least currently is) the same as the XAPI version in XenServer.
Cutting-edge does not need to mean unstable, in fact I think it is
understood that regular stable versions of xapi will be available and
get integrated into XCP/XAPI-based distributions (like XCP and
XenServer) as the maintainers of those projects/products see fit.

As long as xapi remains unified, there is no fragmentation. When
working with a custom XCP, XCP itself, or XenServer the question will
be what version of XAPI is available? This will determine the feature
set available underneath. This is the way management tools like
XenCenter, CloudStack etc. *should* work. We need to move away from
relying on a specific version of XCP, XenServer, etc. and instead rely
on specific feature sets or versions of xapi itself.

I propose that at some point over the course of this year (after an
official release of Project Kronos is out the door) that we have a
XAPI/XCP hackathon. We can invite XAPI/XCP devs to it and also have a
devops-based track that proposes projects based on custom XCP(-full)
setups that may or may not need explicit help from XAPI itself. I
invite you to start brainstorming ideas, but while you do that check
out the great material that came out of the Xen Day [3] last week.
This material will inspire you to want to hack on xapi, or write
scripts for it, or create your own HA/FT solution based on DRDB and
pacemaker.

The momentum around XAPI/XCP is ours to take into the future of the
data center and the cloud. Go forth and use XCP or xcp-xapi, or choose
to get support from a vendor like Citrix and run XenServer.

...What are you going to build today?

[1] http://www.slideshare.net/deshantm/project-kronos-openstackdesignsummit
[2] http://www.slideshare.net/deshantm/why-choose-xen-for-your-cloud
[3] http://xen.org/community/xenday11.html

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