Building Images for Taskotron Disposable Clients

[Tim Flink]

As we get closer to putting disposable clients into production, we need
a way to have updated images for those clients. I don't think this is
news to anyone since the topic has come up several times before but now
there's a bit more urgency :)

In my mind, we have the following requirements:
 - Produces qcow2 images that work with testcloud
 - can be run in an automated way
 - allows adding/changing/customizing packages contained in image
 - allows arbitrary repos to be specified

and the following "nice to have" things:
 - can build branched and rawhide images
 - builds images from scratch using only things provided by releng
 - written in python
 - builds more than qcow2 for some future-proofing
 - can run well in a VM

Is there anything that I missed?

As far as I know, we're looking at two options right now:
taskotron-vmbuilder and imagefactory. I've put together a list of
the pros and cons that I know of for both tools. Thoughts on which
direction to take would be appreciated.

Tim


taskotron-vmbuilder [1] is a PoC system kparal built around
virt-builder [2]. Images are specified in a yaml file and instead of
building those images from scratch "It takes cleanly prepared, digitally
signed OS templates and customizes them".

[1] https://bitbucket.org/fedoraqa/taskotron-vmbuilder
[2] http://libguestfs.org/virt-builder.1.html

pros:
 - already does almost everything we need
 - fits all requirements
 - builds quickly
 - well supported

cons:
 - requires blobs which are out of our control
   * yes, I know who does the work behind virt-builder. My concern
     isn't with him, it's the general concept that I don't like. This
     also gets into the fact that we would have pretty much no control
     over timing of release for the base images.
 - limited support for rawhide and branched releases
 - limited support for non-server spins
 - output images are large in size
 - virt-builder is not written in python


imagefactory [3] is a system for building os images and potentially
shipping those images to various cloud systems. Images are specified
with a kickstart file and an xml template descriptor. Imagefactory
builds images from scratch, essentially using the kickstart to run an
install inside a VM and processing that install into the desired image
type.

[3] http://imgfac.org/

pros:
 - used by releng to create Fedora cloud images
 - builds images from packages: no blobs that we don't have control over
 - already has a mostly-complete RESTful api that can list images and
   trigger new builds
 - can support almost all spins; anything that can be represented in a
   kickstart
 - written in python

cons:
 - not as fast as virt-builder
 - somewhat more complex than virt-builder
 - when something goes wrong, debugging can be difficult due to how the
   tool works
 - we may be somewhat on our own to fix issues if releng is not hitting
   similar problems
 - may not run well in a VM (would need nested virt)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/qa-devel/attachments/20151109/4e950db2/attachment.sig>