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? :)