From: Eldon Stegall <eldon-qemu@eldondev.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>, "John Snow" <jsnow@redhat.com>
Subject: Re: no more pullreq processing til February
Date: Thu, 26 Jan 2023 18:41:50 +0000 [thread overview]
Message-ID: <Y9LJbvFf0N3BJBKq@invalid> (raw)
In-Reply-To: <Y9KQX2pa6I7n/uvT@redhat.com>
On Thu, Jan 26, 2023 at 02:38:23PM +0000, Daniel P. Berrangé wrote:
> The current approach for provisioning our private runners is highly
> undesirable IMHO. We are installing the full set of build deps on
> the host OS install, at time of provisioning the runner.
>
> We should instead be provisioning the hosts exclusively to have
> docker, and then use containers for the build + test environment,
> so we don't need to have sysadmin intervention on the runners when
> a merge request adds a build dep.
>
> If we want to new private runners to replace the shared runners
> transparently, then the use of docker is basically a must have.
This is how I currently do yocto builds for my current primary concern,
provision the machines, and the docker-compose run the tests and builds.
As far as baremetal goes, I find authenticated IPXE scripts work well
for a number of these scenarios, and permit very dynamic allocation of
resources. I have been a fan of the ignition/coreos/fcos strategy for
baremetal deployment due to the capability to run the full system in
memory, as writing packaging to disk can waste time and flash in my
opinion. I strongly agree with the benefits of managing these components
in the repo. Dockerfile, ignition config, or cloud-config would probably
work. Dockerfile makes sense to me if existing work in that direction
has interest and docker is sufficiently flexible for the tests. That
said, it may be easier to generate an appropriate cloud-config if no
work is yet done on running tests inside docker.
I have looked through the .gitlab-cl.d directory in the repo, and it
seems that there is existing work done with containers in the
container-template.yml. Do we also incur minutes for our cirrus builds
equivalent to the duration of the build on cirrus? Maybe relocation
those builds would be the most effective? It seems that a number of
builds unrelated to cirrus use containers already, or I am missing
something?
I will try to familiarize myself further with this directory. I will try
adding some runners to my fork and seeing what the tests look like
there.
Thanks,
Eldon
next prev parent reply other threads:[~2023-01-26 18:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 13:22 no more pullreq processing til February Peter Maydell
2023-01-26 13:52 ` Eldon Stegall
2023-01-26 14:13 ` Alex Bennée
2023-01-26 14:27 ` Peter Maydell
2023-01-26 14:38 ` Daniel P. Berrangé
2023-01-26 18:41 ` Eldon Stegall [this message]
2023-01-27 9:53 ` Daniel P. Berrangé
2023-01-26 14:18 ` Daniel P. Berrangé
2023-01-26 14:30 ` Daniel P. Berrangé
2023-01-27 8:50 ` Gerd Hoffmann
2023-01-26 13:57 ` Alex Bennée
2023-01-26 14:07 ` Daniel Henrique Barboza
2023-01-26 14:27 ` Daniel P. Berrangé
2023-01-26 14:35 ` Daniel P. Berrangé
2023-01-26 14:41 ` Peter Maydell
2023-01-26 18:17 ` Thomas Huth
2023-01-26 20:49 ` Alex Bennée
2023-01-26 14:25 ` Stefan Hajnoczi
2023-01-26 14:28 ` Peter Maydell
2023-01-27 7:36 ` Thomas Huth
2023-01-27 12:39 ` Kevin Wolf
2023-01-27 12:47 ` Daniel P. Berrangé
2023-01-27 13:11 ` Peter Maydell
2023-01-27 13:12 ` Peter Maydell
2023-02-01 16:18 ` Peter Maydell
2023-01-27 9:30 ` Markus Armbruster
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=Y9LJbvFf0N3BJBKq@invalid \
--to=eldon-qemu@eldondev.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.