On Tue, Oct 20, 2020 at 08:58:39AM +0200, Erik Skultety wrote: > On Mon, Oct 19, 2020 at 04:41:38PM -0400, Cleber Rosa wrote: > > On Mon, Oct 19, 2020 at 12:26:10PM +0200, Erik Skultety wrote: > > > On Sun, Oct 18, 2020 at 09:50:02PM -0400, Cleber Rosa wrote: > > > > To have the jobs dispatched to custom runners, gitlab-runner must > > > > be installed, active as a service and properly configured. The > > > > variables file and playbook introduced here should help with those > > > > steps. > > > > > > > > The playbook introduced here covers a number of different Linux > > > > distributions and FreeBSD, and are intended to provide a reproducible > > > > environment. > > > > > > > > Signed-off-by: Cleber Rosa <cr...@redhat.com> > > > > Reviewed-by: Daniel P. Berrangé <berra...@redhat.com> > > > > --- > > > > > > In general, there's been put quite some effort into the playbooks - sorry > > > I'm > > > late to the game - is there a plan to introduce QEMU as a project to > > > lcitool? > > > > I think it's becoming quite clear that having so much duplication (in > > the dockerfiles, tests/vm, this playbook, etc) is costly and error > > prone. I don't know if anyone has invested time in a PoC to > > consolidate those (with lcitool), but I can certainly see the upside > > to that. BTW, are you volunteering (wink wink)? :) > > I don't think I was trying to :), but sure, I can dedicate some time to it. > I'll need a bit of guidance in the QEMU world though for sure.
I think the obvious and easy place is start using lcitool is for the tests/docker/dockerfiles/*. All that's required is to add mappings to lcitool for the various deps that QEMU has which libvirt does not already have. Then we should be able to start auto-generating the dockerfiles without too much difficulty. This will be a significant step forward because it will help us keep te package lists in sync across all the dockerfiles which is a major fail in QEMU right now. Dealing with tests/vm replacement or these ansible recipes is likely to be a significantly more challenging proposition. Perhaps we can again start by just automating creation of the package lists that the tests/vm and ansibile recipes need, as again those are all inconsistent. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
