Building Images for Taskotron Disposable Clients

[Kamil Paral]

> My vote would be for imagefactory. In my mind, it comes down to the blob
> vs. from-scratch thing, using the same tools that releng does and the
> fact that imagefactory is completely written in python.
> 
> Whether we use the API or not is a different question, though :)

I think both tools are capable of doing what we need and the amount of required work will be similar. The blob argument disappears if we create and host our own templates. The collaboration factor is important and having some kind of API is also a good thing (even though I haven't seen it yet and I don't know what we would use it for). I don't think we will patch that too much (if we need to submit nontrivial patches, we're likely using a wrong tool, I don't think we should be spreading ourselves even thinner than we are now), so the implementation language is not a big deal, I think. Hosting and downloading might be easier with virt-builder, because it already supports querying remote image templates index and downloading selected files.

There is one view angle that we should consider as well, I think, which is the task-developer use case. For our production use case, it doesn't really matter how fast the compose process it or how large the disk images are. But how are the task developers going to use them? If they're going to download them (and periodically update them, even several times per week), we want the images as small as possible. If they're going to build them locally, we want them built fast and with small download sizes (the virt-builder template saves some data from downloading, only updates are downloaded; also there's a question whether we could cache the downloaded packages somehow with some of these tools). Or will we offer both approaches, let them pick what works best for them?

If we intended to mostly build those images on dev's computers, I'd probably prefer virt-builder. But my current impression is that local building will be a secondary option, and we'll primarily offer pre-created images for download (even downloading them automatically). Which makes sense, it's easier for the dev, and less error-prone. So in that light (assuming no one has different plans in mind), it doesn't really matter which technology we choose to build it. Image size is a factor here, though. I don't have any real numbers here, it would be very interesting to see the same image (same package set, same filesystem size) built by both tools and compare the output size (ideally even after running zerofree on them and compressing them). My guess is that they should have the same size (what would cause a difference?), but we might be surprised. Do we have a volunteer to test this? :)