[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] Xapi Project 2.0 release



On 06/02/2014 04:41 PM, Dave Scott wrote:
Hi George,

On 2 Jun 2014, at 14:13, George Shuklin <george.shuklin@xxxxxxxxx> wrote:

On 06/02/2014 03:59 PM, Jon Ludlam wrote:
Hi all,

It's about time we had a release!

There has been a huge amount of effort been spent over the last year or
so since we joined the Linux Foundation, and we're almost at the point
where the master branch of the xapi-project repositories can be used to
manage VMs in several different environments. So the main goal of this
release is that it works without source change on XenServer, CentOS 6.5
and Ubuntu 14.04. Note that this will be a source only release, as with
standard xen-project releases.

What we need to do is agree as a community what we need to do before we
hit the release button. We had a good starting discussion at the Xen
Hackathon last week, which I'll summarise here:

* Needs to pass 'exercise.sh' tests on Ubuntu 14.04 and CentOS 6.5 (via
buildroot packages).
* On XenServer, we can exploit the Citrix internal tests (nightly and
stress), which need to pass with 'reasonable' rates.
* All OCaml libraries must be available in opam - either through
xapi-project/opam-repo-dev or (preferably) the standard opam repository.
* Need to be able to bypass xcp-networkd taking over the management of
the networking on the host.
* Documentation! We need at least installation, basic usage, and how to
contribute, including build instructions.

So, if anyone else has any suggestions for what needs to be done before
release, please reply and we'll gather together a list of requirements.

Also, we'll need to track the todo list. Anybody have any preference for
where to do this? wiki.xenproject.org? Github issues?


I don't want to sound to skeptical, but after about 5 year of deep work with 
xapi, I was really disappointed by Citrix VS opensource relationship. XenServer 
was and is not libre. There is source code but there is no way to rebuild 
original ISO from those sources. Decisions were made purely in-house sole by 
Citrix, and published opensource version (xapi packages) were broken beyond 
repair (and were removed from repository).
I agree that the inability to rebuild the ISO from sources is a big problem. We’ve been working on 
this slowly over the past year and have now reached a point where the ‘master’ branch of xapi 
(and associated tools) should build on a modern Linux distro. Since there are a set of libraries we depend 
on we’ve created this repo:

https://github.com/xenserver/buildroot

— it contains “spec” files for all these dependencies. If you fire up a CentOS 
6 or an Ubuntu trusty box you should be able to clone that repo and type

./configure.sh
make
make install

I’ve switched over to using this as my primary development environment now since it’s 
the most convenient way (especially combined with a client hypervisor like virtualbox on a laptop). 
Note that it builds the latest bleeding-edge version of the code, so it’s not 
production-ready yet.

I also agree that our previous attempt to publish open source packages weren’t really usable. The 
old version of the code had so many dependencies on a customised CentOS distro that the packages needed a 
very large patch queue to build. The patch queue created effectively a fork of the code that we 
couldn’t afford to maintain. Merging these patches into the ‘master’ branch has taken 
about a year but is done now (more or less).

Therefore I think one of the “xapi 2” release criteria should definitely be “all the 
portability patches have been merged” so that clean packages can be created.



Glad to hear that.

But still, how about problems with LVM patches? As far as I know there is a bug ugly patch over lvm2 tools in XenServer. This patch will never be accepted to upstream, and lack of that patch kills completely LVMoISCSI SR. I never saw source of ISO installator and patches for Centos/RHEL installers for elilo.

And, the main question: governance. Personally I think XenServer made a horrible mistake when adopted VHD format - and because Citrix is completely control of XenServer development, there is no chances to undo that. And Citrix is more interested in VDIs than everything else...


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.