Re: [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook

[Daniel P . Berrangé]

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 <crosa@redhat.com>
> > > > Reviewed-by: Daniel P. Berrangé <berrange@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 :|