From: Cleber Rosa <crosa@redhat.com>
To: Erik Skultety <eskultet@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
"Beraldo Leal" <bleal@redhat.com>,
"Stefan Hajnoczi" <stefanha@gmail.com>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Andrea Bolognani" <abologna@redhat.com>,
"Willian Rampazzo" <wrampazz@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Eduardo Habkost" <ehabkost@redhat.com>
Subject: Re: [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook
Date: Mon, 19 Oct 2020 16:41:38 -0400 [thread overview]
Message-ID: <20201019204138.GC1617151@localhost.localdomain> (raw)
In-Reply-To: <20201019102610.GB495479@nautilus>
[-- Attachment #1: Type: text/plain, Size: 6601 bytes --]
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)? :)
> We've taken care of most of the bits in the playbooks that are being introduced
> and for the remaining ones I think it would be that big of an overhaul to do
> the adjustments. One major re-factor though would IMO be to break the
> dependency lcitool has on the machine naming, kind of restricting it to a
> limited set of hosts and corresponding names (e.g. libvirt-fedora-32) which
> makes it inconvenient to prepare physical hosts.
>
Right... I wasn't aware of that depedency. And, this may be a nice
project to make sure that lcitool doesn't have any other libvirt
specificities.
> More comments inline...
>
> > docs/devel/ci.rst | 63 ++++++++++++++++++++++++++
> > scripts/ci/setup/.gitignore | 1 +
> > scripts/ci/setup/gitlab-runner.yml | 72 ++++++++++++++++++++++++++++++
> > scripts/ci/setup/vars.yml.template | 13 ++++++
> > 4 files changed, 149 insertions(+)
> > create mode 100644 scripts/ci/setup/.gitignore
> > create mode 100644 scripts/ci/setup/gitlab-runner.yml
> > create mode 100644 scripts/ci/setup/vars.yml.template
> >
> > diff --git a/docs/devel/ci.rst b/docs/devel/ci.rst
> > index 208b5e399b..a234a5e24c 100644
> > --- a/docs/devel/ci.rst
> > +++ b/docs/devel/ci.rst
> > @@ -84,3 +84,66 @@ To run the playbook, execute::
> >
> > cd scripts/ci/setup
> > ansible-playbook -i inventory build-environment.yml
> > +
> > +gitlab-runner setup and registration
> > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > +
> > +The gitlab-runner agent needs to be installed on each machine that
> > +will run jobs. The association between a machine and a GitLab project
> > +happens with a registration token. To find the registration token for
> > +your repository/project, navigate on GitLab's web UI to:
> > +
> > + * Settings (the gears like icon), then
> > + * CI/CD, then
> > + * Runners, and click on the "Expand" button, then
> > + * Under "Set up a specific Runner manually", look for the value under
> > + "Use the following registration token during setup"
> > +
> > +Copy the ``scripts/ci/setup/vars.yml.template`` file to
> > +``scripts/ci/setup/vars.yml``. Then, set the
> > +``gitlab_runner_registration_token`` variable to the value obtained
> > +earlier.
> > +
> > +.. note:: gitlab-runner is not available from the standard location
> > + for all OS and architectures combinations. For some systems,
> > + a custom build may be necessary. Some builds are avaiable
> > + at https://cleber.fedorapeople.org/gitlab-runner/ and this
> > + URI may be used as a value on ``vars.yml``
>
> Yes, this can be suboptimal...Would it make sense to fall back to build the
> binary of a given version from git as a fallback during this playbook if the
> necessary arch version isn't provided the official way? Just an idea, I'd like
> to avoid the need for you to become the maintainer of the binaries and keep up
> with the releases.
>
Well, building them during the playbook would be a lot more
complex... You can have your own repo with your own builds, and just
tweak your vars.yml.
> > +
> > +To run the playbook, execute::
> > +
> > + cd scripts/ci/setup
> > + ansible-playbook -i inventory gitlab-runner.yml
> > +
> > +.. note:: there are currently limitations to gitlab-runner itself when
> > + setting up a service under FreeBSD systems. You will need to
> > + perform steps 4 to 10 manually, as described at
>
> Which one of them is considered an automation problem? In lcitool we made
> gitlab-runner completely automated on all distros, including FreeBSD:
>
It looks like lcitool went the more practical route. I was hoping to
not have to treat gitlab-runner in such a special way in any
"supported" OS. What I mean is, I'd rather write the code within
gitlab-runner (or reespective libraries). Of course, I did not get to
it, so that's why I just documented the steps here.
I'll take a look at lcitool's playbook to see if I can easily
canibalize some of that. But, at this time, we don't runners for
FreeBSD anyway, so I guess this is not *that* urgent.
> 4) log file permissions - you're creating the user, you can as well create the
> file with correct permissions
>
> 5) ensure /usr/local/etc/rc.d exists - once you execute build-environment.yml
> it will pull a bunch of dependencies which ensure the dir exists
>
> 6) gitlab_runner service script should IMO provided by this automation as a
> template and install to the correct location
>
> 7) ensure the service script is executable - template module can do that
>
> 8) register the runner - you're doing that
>
> 9) enable the service - Ansible's service module is generic and supports
> init/OpenRC
>
> 10) I don't see a step 10
>
This was either a mistake or the installation steps got updated. I'll
adjust that.
> IOW I think there should be as little manual intervention as possible and in
> this case I don't think any manual steps are needed by the user.
>
Agreed. I was not super happy with the current state of this playbook
wrt FreeBSD, but I decided to pick other battles to fight. Also,
newer gitlab-runner versions *may* be using the updated service
management lib, which may reduce/remove the need for custom handling.
Anyway, I'll look at what can be improved here, considering the cost.
Thanks!
- Cleber.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-10-19 20:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 1:49 [PATCH v4 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 1/4] Jobs based on custom runners: documentation and configuration placeholder Cleber Rosa
2020-10-21 6:45 ` Thomas Huth
2020-11-09 15:17 ` Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 2/4] Jobs based on custom runners: build environment docs and playbook Cleber Rosa
2020-10-19 10:27 ` Erik Skultety
2020-10-19 20:25 ` Cleber Rosa
2020-10-20 6:18 ` Erik Skultety
2020-11-09 15:20 ` Cleber Rosa
2020-10-20 17:52 ` Andrea Bolognani
2020-11-09 16:37 ` Cleber Rosa
2020-11-10 17:27 ` Andrea Bolognani
2020-10-21 7:00 ` Thomas Huth
2020-11-09 16:39 ` Cleber Rosa
2020-10-19 1:50 ` [PATCH v4 3/4] Jobs based on custom runners: docs and gitlab-runner setup playbook Cleber Rosa
2020-10-19 10:26 ` Erik Skultety
2020-10-19 20:41 ` Cleber Rosa [this message]
2020-10-20 6:58 ` Erik Skultety
2020-10-20 8:29 ` Daniel P. Berrangé
2020-10-20 18:13 ` Andrea Bolognani
2020-10-19 20:54 ` Cleber Rosa
2020-10-20 7:00 ` Erik Skultety
2020-10-19 1:50 ` [PATCH v4 4/4] Jobs based on custom runners: add job definitions for QEMU's machines Cleber Rosa
2020-10-19 10:29 ` Daniel P. Berrangé
2020-10-19 10:42 ` Philippe Mathieu-Daudé
2020-10-19 20:17 ` Cleber Rosa
2021-01-28 11:51 ` [PATCH v4 0/4] GitLab Custom Runners and Jobs (was: QEMU Gating CI) Thomas Huth
2021-02-03 21:06 ` Cleber Rosa
2021-02-04 11:27 ` Thomas Huth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019204138.GC1617151@localhost.localdomain \
--to=crosa@redhat.com \
--cc=abologna@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=bleal@redhat.com \
--cc=ehabkost@redhat.com \
--cc=eskultet@redhat.com \
--cc=fam@euphon.net \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=thuth@redhat.com \
--cc=wainersm@redhat.com \
--cc=wrampazz@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).