|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-API] Xapi Project 2.0 release
On 06/02/2014 06:26 PM, Jon Ludlam wrote: 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).On 02/06/14 14:13, George Shuklin wrote: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).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. 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. Is buildroot cover tests for shell scripts? If you compare neutron ovs plugin code to xensource scripts - ovs got very neat tests and constant configuration checking. Xensource scripts do not check configuration, they blindly change configuration with expectation of perfectly sane environment (inside OVS config). This is on of 'tighly build' part of xenserver, which cause huge pain in case of slightest changes in host environment.Does something really changed here? I see lot of problems in xapi VS community relationship and Citrix is kinda not opensource company (Presentation Server, World of Windows and so on). Xensource was bit unexpected addition to this tight and cozy wold of Citrix and Microsoft, and source publication is not made xapi libre software. Only 'open source', but not libre.Yes, something has changed. For example, the problem back when we got xapi into Debian was that we had to get _much_ too involved in the packaging process - it wasn't simply a case of grabbing the source tarballs, building and packaging them - it effectively meant that a few of us had to spend several months making the thing work at all, and those patches ended up in the debian source package, rotting gently while the master branch moved on. There was no way back then that xapi could ever have been packaged up from source by anyone other than us. This is _very_ different from now. We've spent a long time splitting repositories up, adding standard build system files, removing hard-coded paths, splitting things up into more sensible smaller chunks and generalizing the code. We've split two massive monolithic repositories (xen-api and xen-api-libs) into about 30 smaller more sensible ones. By the time of the release, the installation workflow should for these individual repositories should simply be 'clone from github', then 'configure', 'make', 'make install', and you should be there, and I think it's entirely reasonable that someone with a working Xen installation could package it up successfully. Of course, simply building is not enough. The buildroot repository demonstrates that, with a minimum of patching (we've still got patches for xcp-sm, vncterm and opasswd, but these will be fixed before the release) viable packages can be created that work well enough to run VMs to OpenStack's satisfaction. I'm aware that this doesn't address all of your concerns. But I believe it's a really good first step, and hopefully our next steps will all go in the same direction too :-) 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). I think that part is much more important for wide adoption than perfection of xapi itself. _______________________________________________ Xen-api mailing list Xen-api@xxxxxxxxxxxxx http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |