Please note, that XCP is opensourced Xen Server. It has been closed for
long long time and current opensoursization is still in progress.
XenSource/Citrix shipped it as binary ISO with "please don't change
anything" with disabled CentOS mirrors and separate update system.
It was much easy to maintain own single copy of all files than fights
with upstream for every change (and those fight was lost once when -xen
was removed from linux upstream).
Right now things changes, and steady upstreamization of xapi can be very
good (but hard) work.
Yes, I do really wants to have apt-get install xencloudplatform with
automatically resolved dependence to xapi, squeezed and so on/
But this is very very very long way.
В Чтв, 05/05/2011 в 00:45 +0800, Thomas Goirand пишет:
> On 05/04/2011 05:07 PM, Jonathan Ludlam wrote:
> > A shortlist of modified packages: LVM, biosdevname, dm-multipath,
> > e2fsprogs, ethtool, open-iscsi, kexec. There are more, but these
> > are the more important ones.
>
> Gosh, I didn't know there was that much things involved, and frankly, I
> don't understand why you had to modify that many things. It'd be great
> if there was an effort to have everything upstreamed...
>
> > The trouble is that XCP has been developed as an integrated
> > system rather than an addon set of packages for an existing
> > operating system. While it's not *far* off from being the
> > latter, it would take quite a bit of effort both to figure
> > out all the reason why each RPM has been patched
>
> Especially for someone not part of the original team who built it, and
> with so few information about XCP's internals on the web!
>
> > not to mention
> > all the implicit dependencies that we have on the behaviour of
> > the underlying OS. We'd then have to figure out on a case-by-case
> > basis whether the patch was general enough to upstream, and if
> > not, whether a workaround existed that avoids the need of the
> > patch, and if not, we'd have to patch the debs.
>
> I strongly believe that the above is vital for XCP to continue to exist
> in the long run. Sooner or later, you'll have a dependency hell trying
> to upgrade to CentOS 6, or things like that.
>
> > I think it could be made to work without *too* much effort so
> > long as you were willing to sacrifice some bits of functionality.
>
> I'm currently only interested in having the needed bits so that
> Openstack can run with Xen, which I prefer over KVM. I've been told by
> the people from RackSpace, that Openstack uses XCP for Xen. I'm not
> interested to run CentOS at all (I'm a Debian Developer and work
> exclusively with Debian), so my only option was to build the needed
> things Openstack is using from XCP so that they run in Debian. I'm sure
> other operating systems would have benefit from this work too.
>
> I've added the openstack list to this thread, in the hope that someone
> will be able to tell which bit from XCP is required by Openstack. If
> there's not too much work involved, I'll go forward with my initial
> idea, if not, I regret to say that I'll have to forget about Xen with
> Openstack (unless using libvirt becomes an OK solution as well).
>
> > I would guess that you could get an XCP system up and running on
> > ubuntu within a couple of weeks or so, but it probably wouldn't
> > be able to do LVM based storage backends, and I would guess a
> > fair bit of the more advanced networking bits and pieces would
> > require more effort.
>
> FYI: I'm working on Debian packaging only (eg: not Ubuntu). I'm not sure
> if Ubuntu guys will restart pulling Xen packages from SID (at some
> point, Ubuntu dropped Xen support), but as dom0 support from kernel.org,
> it's likely this will happen (as they will only need the Xen hypervisor
> package from Debian). So if that happens, and I (with I hope, a bit of
> your help) do the packaging work to have the needed XCP bits in Debian,
> then we can reasonably hope to have Openstack to work flawlessly with
> Xen and xapi, in both Debian and Ubuntu.
>
> Hoping to get feedback from both Openstack and Citrix developers, so we
> can see what can be done,
> Cheers,
>
> Thomas Goirand (zigo)
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
Home