Created
January 7, 2016 11:54
-
-
Save jonludlam/ac582e0da94b5d56ee48 to your computer and use it in GitHub Desktop.
Blog post
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
New year, new way to develop for XenServer! | |
Building bits of XenServer outside of Citrix has in the past been a | |
bit of a challenging task, requiring careful construction of the build | |
environment to replicate what 'XenBuilder', our internal build system, | |
puts together. This has meant using custom DDK VMs or carefully | |
installing by hand a set of packages taken from one of the XenServer | |
ISOs. With XenServer Dundee, this will be a pain of the past, and a | |
making build environment will be just a 'docker run' away. | |
Part of the work that's being done for XenServer Dundee has been | |
moving things over to using standard build tools and packaging. In | |
previous releases there have been a mix of RPMs, tarballs and patches | |
for existing files, but for the Dundee project everything installed | |
into dom0 is now packaged into an RPM. Taking inspiration and | |
knowledge gained while working on | |
[buildroot](https://github.com/xenserver/buildroot/), we're building | |
most of these dom0 packages now using mock. Mock is a standard tool | |
for building RPM packages from source RPMs (SRPMS), and it works by | |
constructing a completely clean chroot with only the dependencies | |
defined by the SRPM. This means the everything needed to build a | |
package must be in an RPM, and the dependencies defined by the SRPM | |
must be correct too. | |
From the point of view of making reliably reproducible builds, using | |
mock means there is very little possibility of having the build | |
dependent upon the the environment. But there is also a side benefit | |
of this work: If you actually want to rebuild a bit of XenServer you | |
just need to have a yum repository with the XenServer RPMs in, and use | |
'yum-builddep' to put in place all of the build dependencies, and then | |
building should be as simple as cloning the repository and typing | |
'make'. | |
The simplest place to do this would be in the dom0 environment itself, | |
particularly now that the partition size has been bumped up to 20 gigs | |
or so. However, that may well not be the most convenient. In fact, for | |
a use case like this, the mighty Docker provides a perfect | |
solution. Docker can quickly pull down a standard CentOS environment | |
and then put in the reference to the XenServer yum repository, install | |
gcc, OCaml, git, emacs and generally prepare the perfect build | |
environment for development. | |
In fact, even better, Docker will actually do all of these bits for | |
you! The docker hub has a facility for automatically building a | |
Docker image provided everything required is in repository on Github. | |
So we've prepared a [repository](https://github.com/xenserver/xenserver-build-env) | |
containing a Dockerfile and associated gubbins that sets things up | |
as above, and then the docker hub builds and hosts the | |
[resulting docker image](https://hub.docker.com/r/xenserver/xenserver-build-env/). | |
Let's dive in with an example on how to use this. Say you have a | |
desire to change some aspect of how networking works on XenServer, | |
something that requires a change to the networking daemon itself, | |
'xcp-networkd'. We'll start by rebuilding that from the source RPM. | |
Start the docker container and install the build dependencies: | |
$ docker run -i -t xenserver/xenserver-build-env | |
[root@15729a23550b /]# yum-builddep -y xcp-networkd | |
this will now download and install everything required to be able to | |
build the network daemon. Next, let's just download and build the | |
SRPM: | |
[root@15729a23550b /]# yumdownloader --source xcp-networkd | |
At time of writing, this downloads the SRPM | |
"xcp-networkd-0.9.6-1+s0+0.10.0+8+g96c3fcc.el7.centos.src.rpm". This | |
will build correctly as is: | |
[root@15729a23550b /]# rpmbuild --rebuild xcp-networkd-* | |
... | |
[root@15729a23550b /]# ls -l ~/rpmbuild/RPMS/x86_64/ | |
total 2488 | |
-rw-r--r-- 1 root root 1938536 Jan 7 11:15 xcp-networkd-0.9.6-1+s0+0.10.0+8+g96c3fcc.el7.centos.x86_64.rpm | |
-rw-r--r-- 1 root root 604440 Jan 7 11:15 xcp-networkd-debuginfo-0.9.6-1+s0+0.10.0+8+g96c3fcc.el7.centos.x86_64.rpm | |
To patch this, it's just the same as for CentOS, Fedora, and any other | |
RPM based distro, so follow one of the | |
[many](http://www.owlriver.com/tips/patching_srpms/) | |
[guides](https://wiki.centos.org/HowTos/RebuildSRPM) | |
[available](http://unix.stackexchange.com/questions/16904/how-to-unpack-modify-rebuild-and-install-a-srpm). | |
Alternatively, you can compile straight from the source. Most of our | |
software is hosted on github, either under the xapi-project or | |
xenserver organisations. xcp-networkd is a xapi-project repository, so | |
we can clone it from there: | |
[root@15729a23550b /]# cd ~ | |
[root@15729a23550b ~]# git clone git://github.com/xapi-project/xcp-networkd | |
Most of our RPMs are carefully versioned, and where these are from git | |
repositories the version information comes from 'git describe'. | |
[root@15729a23550b ~]# cd xcp-networkd | |
[root@15729a23550b xcp-networkd]# git describe --tags | |
v0.10.0-8-g96c3fcc | |
The important part here is the hash, in this case '96c3fcc'. Comparing | |
with the SRPM version, we can see these are identical. We can now just | |
type 'make' to build the binaries: | |
[root@15729a23550b xcp-networkd]# make | |
this networkd binary can then be put onto your XenServer and run. | |
There's still a way to go before Dundee is released, and some aspects | |
of this still need some work before it's all totally seamless. In | |
particular, we don't currently have a publicly available yum repository, | |
so the one being used in this is currently being constructed from the | |
XenServer ISOs and hosted on my personal website via a [simple | |
script](https://github.com/jonludlam/various-scripts/blob/master/update_xs_yum.sh), | |
and the RPMs themselves are not currently signed. However, by the time | |
Dundee is out the door this should be fixed. Certainly here in Citrix, | |
many of us have switched to using this for our day-to-day build needs, | |
because it's simply far more convenient than our old custom chroot | |
generation mechanism. | |
L21: the everything -> that everything
L69: " as is:" ?
L92: Version numbers carefully constructed automatically containing useful information about the source.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
L9: "a making" -> "making a"