Feature #13031
closedimplement a task that builds packages
0%
Description
- teuthology https://github.com/ceph/teuthology/pull/623
- ceph-qa-suite https://github.com/ceph/ceph-qa-suite/pull/565
Implement a task that builds Ceph packages and make it so they are consumed instead of the gitbuilder packages. The goal is to allow anyone with access to an OpenStack cluster to run a suite without requiring a build from the gitbuilders.
In the build-packages task, the packages are built using :
- make-debs.sh
- make-rpm.sh
And made available via an http server (package server) with a structure identical to http://gitbuilder.ceph.com/ceph-deb-trusty-x86_64-basic/
The build-packages tasks must be run before the tasks that consume its output. This is done by modifying the interal task (see how the kernel task does it for instance):
- teuthology internal tasks looks for the package-build task in the job config
- if the package-build task is found, it is placed before tasks that are known to consume packages
tasks: - build-packages:
- when the package-build task is run, it
- looks for the sha1 to be built in the package server
- if the package server already has the sha1, stop there
- builds the packages by locking a target of the desired os_type, os_version and arch and running something like
mount /dev/vdb /opt ; cd /opt ; git clone + git reset sha1 rm -fr /opt/Ubuntu/trusty ; sudo apt-get update ; sudo rm -fr /var/cache/apt ; sudo ln -s /opt/apt /var/cache/apt ; time\ bash -c 'sudo apt-get install -y htop ccache reprepro git ; ccache -M 5G ; export CCACHE_DIR=/opt/.ccache ; ./install-deps.sh ; NPROC=$(nproc) ./make-debs.sh /opt'
- upload the repository to the package server
- unlock the target
- a suites/debug/build-package.yaml file is added to all ceph-qa-suite branches so that it can be append to the teuthology-suite cli and found when extracting the suite.
This adds ~15 minutes to a run for a fully populated ccache on a 4 core, 16GB RAM instance.
There are many ways to optimize this (sharing repository between jobs targeting the same branch, uploading to third party repositories, creating docker images). But these are not in the scope of this first implementation.
Updated by Loïc Dachary over 8 years ago
here is an optimization idea: when the build-package is done building os_type-os_version for sha1, it makes an openstack snapshot named packages-os_type-os_version-sha1
and whenever it needs to build, it first checks to see if such a snapshot exists. If it does, it boot it and it will start serving the packages
Updated by Loïc Dachary over 8 years ago
here is a crazy idea: when the package needs to build, it looks for the closest sha1 (git topological order), boots it, git pull, and make the package real fast because it benefits from an already populated ccache, except the few files changed by the pull request.
and even better: for each stable branch we run all suites with code coverage (both python and c++) and build a matrix of which test cover which line. Whenever a pull request is published, run all tests that cover the lines changed by the pull request.
not all tests: any subset that covers all lines.
Updated by Zack Cerza over 8 years ago
What do you mean by 'boot' a sha1?
One other issue I see with this current idea is we don't currently have a target whose role is 'packages'. I don't think it'd be very sane to add targets to a job automatically. I haven't had a chance to think this through too much though.
Updated by Loïc Dachary over 8 years ago
We could just to store the sources + ccache dir + repository in a volume instead of storing them in the instance, so that it survives the job run and can be re-used when re-compiling the same release with an added pull request.
So whenever a test needs a repository for this particular ceph sha1, os_type, os_version, arch, it creates a tiny http server instance with the volume mounted on it.
Updated by Loïc Dachary over 8 years ago
I don't think it'd be very sane to add targets to a job automatically. I haven't had a chance to think this through too much though.
Ok. That's good to know.
Updated by Loïc Dachary over 8 years ago
What do you mean by 'boot' a sha1?
I mean boot the image that contains the repository created from a given sha1, just for the purpose of serving it for the duration of the job.
Updated by Loïc Dachary over 8 years ago
Instead of using make-debs.sh or make-rpm.sh, use the scripts from https://github.com/ceph/ceph-build/tree/master/ceph-build/build so that there is no divergence between the packages built within teuthology and those published at ceph.com/{debian,rpm}-{release}
Updated by Loïc Dachary over 8 years ago
- Status changed from In Progress to Resolved