Building Images for Taskotron Disposable Clients

[Tim Flink]

On Fri, 13 Nov 2015 10:02:20 -0500 (EST)
Kamil Paral <kparal at redhat.com> wrote:

> > 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.

Agreed on not spreading ourselves any thinner than we already are. From
my testing of imagefactory's api, it will need a small patch to make it
work for our needs but it's not a big patch, I've just been hoping for
some input upstream before submitting anything.

> Hosting and
> downloading might be easier with virt-builder, because it already
> supports querying remote image templates index and downloading
> selected files.

Unless we're running virt-builder on each virthost, I don't see how
this is relevent.

My thought behind using imagefactory's API was that we could build the
images in one location and each virthost would query that API, looking
for a newer image and downloading the newer image if found.

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

I think that the bigger question here is what the process for
non-taskotron-devs will look like. For disposable client execution, are
we going to have them use base cloud images, our custom images or just
discourage disposable client execution?

There aren't so many devs and so far, they're all capable of figuring
out either way. I'm more worried about what'll happen when we start
telling folks to install libtaskotron and "go nuts".

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

I can give this a try later today - I have both tools installed on a
machine here.

Tim
-------------- 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/20151113/e8a65bd9/attachment.sig>