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 A8D7A7405A for ; Sat, 8 Nov 2025 20:12:43 +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=1762632763; cv=none; b=R9GiZ5Mh7OKUjeSPH4w2OzuMLHNnSHF/0tbTFBxDsGLiN72VW9kLNy97Ih7aw+CXs3QXz8WWoXrjl6Fd8z/Bbpj68EH3isy6UnAMP2ha/VYbsHWstQx+LsEswBIJItHcvhyjQqrfxqi8cjm0Coj86Z8Jy3FyWZHFJ0siQIp0bJs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762632763; c=relaxed/simple; bh=zKya/7BCykFh992FlbdhoK79mjKUlC2ws1YmEKadn+Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dNQfvYtAz1n9qBT7FdDUoktM6RlGMG+j2re7hVsq4wP0szrNEC/jf12yHQ5Ogro1vZUDdZCrxBmsP5iJDSZl1DncjpeugoyEuOdfEFE4cfH0et3AgEUBO6rICSI6uYzwlcSNUHdmNljD9wDA4vqOJy1EE42FnIpqCitr3zFy/6k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KDfXBmLp; 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="KDfXBmLp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 42E9CC4CEF5; Sat, 8 Nov 2025 20:12:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762632763; bh=zKya/7BCykFh992FlbdhoK79mjKUlC2ws1YmEKadn+Y=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=KDfXBmLpOo0h8QSOJNbaaVaR0AZ7s8VhG/0oTNkwzjn6Uo9NugStOeb790ViI5A3i CPEey0vi+oXZDTJ7GRoLQk2iK1L6rdqYqzJLO6SYfiApJn+xYTgq0LNiw6KHTtqp+F VEyDexBakAQuYsxVN9s743lpJQWQAdCh93RdXDsm27gjbV9vxCWsIuRqjy7eY5hc4y e48IQPiFQ0D4VFSCWvVIV5jYFwuvT1XomMXVN84zB3vc5neWhQ0tCLhMqZurqE+yNi sAxG6u+frHzsGbkSrkiMVH5WQm4HhQu9BjV9SY3IHdiLZf8ArPRxel5c5TE22ZoZ+o YTdlzoEX45m3g== Message-ID: Date: Sat, 8 Nov 2025 21:12:40 +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 v2 09/15] bootlinux: fix os detection for 9p build dependency installation To: Chuck Lever , Luis Chamberlain Cc: kdevops@lists.linux.dev, Daniel Gomez References: <20251029-fedora-on-debian-v2-0-ddc6e5bebc15@samsung.com> <20251029-fedora-on-debian-v2-9-ddc6e5bebc15@samsung.com> <7a126e42-a65c-4020-b7b4-3e8c784be593@oracle.com> <9657ff48-8cc0-4ce6-b52c-ef1ab40c7a74@kernel.org> <0439acaf-b96b-4553-9a3a-59cd7134e50b@oracle.com> <52e65c62-70eb-47da-b0e2-c92e5c514cbd@kernel.org> <0551827c-a0bd-4589-b9e4-073aa545ccb0@kernel.org> <54fcdfb8-c343-41ff-9150-dae6c0ef8235@oracle.com> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: <54fcdfb8-c343-41ff-9150-dae6c0ef8235@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/11/2025 17.11, Chuck Lever wrote: > On 11/7/25 6:20 PM, Daniel Gomez wrote: >>>> +- name: Red Hat-specific setup (controller node) >>>> ansible.builtin.import_tasks: redhat/main.yml >>>> when: >>>> - distro_redhat_based|bool >>>> + - bootlinux_9p|bool >>>> + >>>> +- name: Red Hat-specific setup (builder node) >>>> + ansible.builtin.import_tasks: redhat/main.yml >>>> + when: >>>> + - bootlinux_builder|bool >>>> + - ansible_os_family == "RedHat" >>>> >>>> IIUC, this should return the correct ansible_os_family value when builder target >>>> is selected because the task is executed on the guest with --limit baseline:dev. >>> Hi Daniel - >>> >>> None of these tasks will execute if bootlinux_targets == true, AFAICT. >> Sorry, I missed that target. I meant to add that condition too when we use >> ansible_os_family case. >> >>> Why can't this work based on which host the install-deps tasks are >>> running on? That was the original design I had in mind, and seems >>> most Ansible-like. >> I can't replicate the issue. I think we can revert the patch. Here my tests: >> >> fedora: https://github.com/linux-kdevops/kdevops/actions/runs/19183690762 >> debian: https://github.com/linux-kdevops/kdevops/actions/runs/19183543710 > > OK, let me try to be less terse. :-) > > I'd like to see this instance of install-deps look like most of the > others: basically, key off only the ansible_os_family settings. I think > that will be more maintainable. 100%. > > Those settings, however, need to properly reflect the environment where > install-deps is running. For the 9p case, it will run on both the > controller (where the kernel is built) and the targets (where the kernel > is installed); and I think bootlinux even runs the install-deps steps > twice for 9p to deal exactly with that duplication. I think you are referring to "Install essential build tools for 9P builds" task in main.yml + "Install dependencies to build the Linux kernel" in build/9p.yml. The first one executes on the guests while the second one is delegated to the localhost. > > The same is true for the "separate builder" case: the kernel builder > runs on one target node, and the built artifacts are installed on other > target nodes; and bootlinux has to ensure the correct dependencies are > installed everywhere they are needed. This is referring to the task "Install dependencies to build and install the Linux kernel" in main.yml. Which is skipped for 9p (but included through build/9p.yml + delegated_to). > > The way I tried to deal with that was to use "delegate_to:". But I think > you might have advanced a different mechanism, and I missed the > subtleties of that. Or, maybe providing execution locale information on > the Ansible command line just isn't appropriate in these cases. I > haven't thought it through. This is where it gets tricky. I've just found out that delegated tasks to a host that is not included in the scope (such as localhost), do not have gathered facts. https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_delegation.html#delegating-facts That explains why ansible_os_family returns the guest fact (e.g. RedHat guest), not the localhost fact (e.g. Debian host) when we import_tasks: install-deps/main.yml in build/9p.yml. The use of distro_yada_based in patch "bootlinux: fix os detection for 9p build dependency installation" allows to access the fact (os family) via Kconfig for the localhost. But breaks builder and targets sub-roles. > > I'm very happy to help drill into the 9p case that was not working for > you, instead of standing nearby lobbing uninformed suggestions. > Meanwhile, I'll keep a patch that reverts 0e9c8ac8bc68 in my private > tree. > Thanks Chuck. I think the correct approach is to revert patch 0e9c8ac8 "bootlinux: fix os detection for 9p build dependency installation" upstream, while we try to sort this out in 9p. For the revert part, please push: Acked-by: Daniel Gomez FYI, I'm already working on a solution using delegate_facts + hostvars as described in the Ansible documentation link above. That seems to be the right approach. I'll send something soon for testing.