Blog post

gistfile1.txt

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.

L92: Version numbers carefully constructed automatically containing useful information about the source.