From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 4FA25385843E for ; Fri, 8 Jul 2022 10:47:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4FA25385843E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0e.wildebeest.org [172.31.17.144]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 28704302AB2C; Fri, 8 Jul 2022 12:47:10 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id CA49E2E81623; Fri, 8 Jul 2022 12:46:53 +0200 (CEST) Date: Fri, 8 Jul 2022 12:46:53 +0200 From: Mark Wielaard To: Christophe Lyon Cc: buildbot@sourceware.org, Szabolcs Nagy , Luis Machado Subject: Re: Arm GDB buildbot workers Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: buildbot@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "The https://builder.sourceware.org/ buildbot" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2022 10:47:13 -0000 Hi Christophe, On Fri, Jul 08, 2022 at 12:11:13PM +0200, Christophe Lyon wrote: > On 7/8/22 01:13, Mark Wielaard wrote: > > OK. See the attached patch, 4 new workers each connected to a gdb CI > > builder. > > They are up and running! \o/ > I'll probably stop/start them several time to make adjustments like > "admin name". Great. In general that should be fine. It might interrupt a build, but that should be retried when the worker comes backup. > > Note that it might be helpful for keeping builds totally separate you > > can use a worker for multiple builders. Depending on the number of > I am not sure to follow? > Why having a worker for multiple builders helps keeping the builds separate? Sorry, I missed a word... "separate, but you" ... > My plan was to have 1 container running a single worker/builder. > That is 4 containers for 4 GDB "configs (distro x target)", 4 containers > for 4 binutils "configs", X containers for X "configs". > > But since these containers would use the same docker image, I think I'll > need to adjust the worker_dir in bb-start.sh, otherwise for instance GDB > and binutils containers/workers/builders would share the same dir, which > won't work (they would compete for the twistd* files etc...) Yes, each worker needs a separate worker dir. Which they normally have in a container unless they share a volume. But I believe that is what you are doing, have a shared bind mounted directory with the host. You can of course start each container with separate --env WORKERNAME environment variables, so you can share the image without hardcoding everything. > Do you instead recommend to have 1 (larger) container per distro x > target, and run binutils/GDB/GCC builders inside this single container? That is what I would recommend for a (virtual) machine. I think it makes some sense for containers too, but maybe having separate containers each with a dedicated worker/builder is smarter in that case? One advantage is that you can more easily control how many builds are running at the same time. If the buildbot sees e.g. 8 different workers it thinks they are all independent and it is fine to start 8 builds in parallel. While if you have one worker you can set max_builds=4 and the buildbot will only start 4 builds at the same time, queuing others. On the other hand with separate containers per worker you can more easily create "small" and "big" workers which handle completely different builds (e.g. you might want a big dedicated gcc builder that may use 32 vpcus at once, while for binutils builds you dedicate a small container that only uses 4 vcpus at a time). We have ncpus vs maxcpus for that, but it isn't as fine grained. Cheers, Mark