public inbox for kdevops@lists.linux.dev
 help / color / mirror / Atom feed
From: Daniel Gomez <da.gomez@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>,
	Luis Chamberlain <mcgrof@kernel.org>
Cc: kdevops@lists.linux.dev, Daniel Gomez <da.gomez@samsung.com>
Subject: Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation
Date: Sat, 8 Nov 2025 21:12:40 +0100	[thread overview]
Message-ID: <e991c6f3-6442-4542-9dde-9f674c07c7a9@kernel.org> (raw)
In-Reply-To: <54fcdfb8-c343-41ff-9150-dae6c0ef8235@oracle.com>

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 <da.gomez@samsung.com>

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.

  reply	other threads:[~2025-11-08 20:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 12:40 [PATCH v2 00/15] Fedora on Debian Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 01/15] base_image: restore locales-all installation for Debian Trixie Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 02/15] guestfs: fix Kconfig indentation style Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 03/15] guestfs: remove unused bringup debug Kconfig options Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 04/15] guestfs: fix spelling errors and Debian capitalization Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 05/15] base_image: set selinux to permissive for fedora on debian hosts Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 06/15] ansible_provisioning: fix help text indentation style Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 07/15] devconfig: fix undefined custom repos/packages variables Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 08/15] devconfig: fix Ansible boolean conditional for custom repos Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation Daniel Gomez
2025-11-07 19:22   ` Chuck Lever
2025-11-07 20:00     ` Daniel Gomez
2025-11-07 20:17       ` Chuck Lever
2025-11-07 20:47         ` Daniel Gomez
2025-11-07 20:53           ` Chuck Lever
2025-11-07 23:20             ` Daniel Gomez
2025-11-07 23:24               ` Daniel Gomez
2025-11-08 16:11               ` Chuck Lever
2025-11-08 20:12                 ` Daniel Gomez [this message]
2025-11-08 20:56                   ` Chuck Lever
2025-10-29 12:40 ` [PATCH v2 10/15] selftests: " Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 11/15] guestfs: generate fedora distribution-specific hostname prefixes Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 12/15] defconfigs: add fedora-41 fragment for guestfs Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 13/15] defconfigs: add debian-13 " Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 14/15] github: add guest OS selection for CI testing Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 15/15] guestfs: increase SSH config timeout for Fedora on Debian hosts Daniel Gomez
2025-10-29 13:49 ` [PATCH v2 00/15] Fedora on Debian Chuck Lever
2025-10-29 14:16 ` Daniel Gomez

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=e991c6f3-6442-4542-9dde-9f674c07c7a9@kernel.org \
    --to=da.gomez@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=da.gomez@samsung.com \
    --cc=kdevops@lists.linux.dev \
    --cc=mcgrof@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox