From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D4F6911713 for ; Tue, 28 Oct 2025 19:53:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761681237; cv=none; b=EKzqCWP/t/Fy7iHSmnaDLflauTUlRIKsThR6CjxCo8GXOhQr/OSzyPda+7Wa3Cy840jQHYwoE1U4D3TmyhBDai0XxBcSn7R5u5FCz0hNRvaTN9mHuWmTmLDIH/BocpAOP0CW4ct8erYwOMVvBjGypLm4MNDxRIyaLCQ6gNtG7v4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761681237; c=relaxed/simple; bh=MeaUktakxyMt0jVWqpiFj1+hYLEPlUlkglr/znFRiR4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jGUQB1hPr/dOg8pc2BGQwPqFGbBA3thu7/djfyn2ajmcp94NI2PKF8bI+HVaR0WCj3x8NaatMAPAQZigH+KWjWa2hS79kEONOUkVzHWua5o+bkT/9q65Ka2PEWX6HpW4kvJKLqMSFSQudSRZ5P9IWX6L2C6ef6ZUbTqObR0G1Eo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aX0VK1zM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aX0VK1zM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90D36C4CEE7; Tue, 28 Oct 2025 19:53:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761681237; bh=MeaUktakxyMt0jVWqpiFj1+hYLEPlUlkglr/znFRiR4=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=aX0VK1zMrIX4l2iMaklORxKu0n0Wr77ngvO1OmIGJo1Ziry4QOVvsf0bZjhKxD9UP K8HOXdkhxz28r4iEeZ53g/bGKUlIqE7RMsm9gb2Mcw2gENzPXWPz7anLsgPlh8nfBs zWmyxDzOmGCELnyxONxySQ1f0uyvfcJ+xU5sZDmhrjs20F0sI5Jl4t3nf0bRxp3Z6X sW5SYPqy3WAK4Ls2uHf8wtw5ouTLfM/OYQIkwdqrpkw/af5ijF7mFvC1KbTblsfZ+8 9r/r4aUk4YpWEpqvzV4SiOmveKkLVMzO+ufaklOKPb9CcwHVvfZbsuBUGWZx1oBa74 S/jsWY5BvxqGw== Message-ID: Date: Tue, 28 Oct 2025 20:53:54 +0100 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Daniel Gomez Subject: Re: [PATCH 09/14] bootlinux: fix os detection for 9p delegated tasks with registered facts To: Chuck Lever , Luis Chamberlain Cc: kdevops@lists.linux.dev, Daniel Gomez References: <20251028-fedora-on-debian-v1-0-1802ab2f993a@samsung.com> <20251028-fedora-on-debian-v1-9-1802ab2f993a@samsung.com> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 28/10/2025 19.51, Chuck Lever wrote: > On 10/28/25 2:11 PM, Daniel Gomez wrote: >> From: Daniel Gomez >> >> When using 9P builds, the Linux kernel is built once on the control >> host (delegate_to: localhost, run_once: true) and shared to all guests. >> The dependency installation tasks reference ansible_os_family which >> gets overwritten when gathering facts from localhost, causing the wrong >> distribution's packages to be installed. > > Just curious: Doesn't kdevops already have variables (eg, distro_debian) > that contain this state? You're spot on. To be clear, I don't like this approach, but I couldn't "gather" ansible_os_family from the localhost and use it directly. The reason is because of the inventory scope we run this playbook on: Example: make linux ... + ansible-playbook --limit baseline:dev playbooks/bootlinux.yml \ '--extra-vars=target_linux_git=/mirror/linux.git target_linux_tree=linux \ target_linux_ref=v6.15... ==> [linux] PLAY: BOOTLINUX TASK: Gathering Facts [kci-18884852820-153-nvme] ⠀⠀✓ [kci-18884852820-153-nvme] TASK: Import optional extra_args file [kci-18884852820-153-nvme] ⠀⠀✓ [kci-18884852820-153-nvme] TASK: Select the .config file for building the test kernel [kci-18884852820-153-nvme] ⠀⠀✓ [kci-18884852820-153-nvme] ... That is gathering facts for the baseline and dev groups. Adding localhost (or all hosts) shouldn't work either, since we don't want the playbook to run on the localhost (controller node), except for some specific tasks. My guess is that it worked before because the guest and the localhost (controller node) happened to match, but we weren't actually collecting the controller node's facts correctly. That gets me thinking if we should run bootlinux.yml localhosts tasks first with a tag (e.g. setup), then run bootlinux on baseline and dev. Or what do you think would be the right approach? >> @@ -1,4 +1,22 @@ >> --- >> +- name: Gather facts from localhost for dependency installation >> + ansible.builtin.setup: >> + filter: "ansible_os_family,ansible_distribution" >> + delegate_to: localhost >> + register: localhost_facts >> + run_once: true >> + >> +- name: Set localhost OS facts for 9P build >> + ansible.builtin.set_fact: >> + localhost_os_family: "{{ localhost_facts.ansible_facts.ansible_os_family }}" >> + localhost_distribution: "{{ localhost_facts.ansible_facts.ansible_distribution }}" >> + delegate_to: localhost >> + run_once: true