On Fri, 13 Nov 2015 10:02:20 -0500 (EST) Kamil Paral <kpa...@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
pgpnn6GiXJsXR.pgp
Description: OpenPGP digital signature
_______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
