From: Daniel Gomez <da.gomez@kernel.org>
To: Chuck Lever <cel@kernel.org>, kdevops@lists.linux.dev
Cc: Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC PATCH 2/2] ansible.cfg: generate an ansible.cfg file in TOPDIR
Date: Mon, 1 Sep 2025 19:07:28 +0200 [thread overview]
Message-ID: <d206bff7-9779-470a-beb7-e3c72de30b2b@kernel.org> (raw)
In-Reply-To: <e9964fba-fe0b-484a-882d-ec41d33f154e@kernel.org>
On 01/09/2025 17.03, Chuck Lever wrote:
> On 9/1/25 8:00 AM, Daniel Gomez wrote:
>> On 28/08/2025 22.28, Chuck Lever wrote:
>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>
>>> I need an ansible.cfg that is generated by the Kconfig menu, but
>>> whose pathname is selected dynamically based on where kdevops is
>>> being run rather than having that path baked into the .config.
>>
>> I'm trying to review the previous conversation before these patches as well as
>> this series. Please, let me know if I'm understanding something wrong:
>>
>> I think what we need is not to have individual configuration paths (as we
>> have now) for ansible.cfg, inventory, etc. What we want is to have one sandbox
>> folder, our TOPDIR, and have our kdevops sandbox directory there. All files
>> generated and consumed by kdevops should then use that path.
>>
>> Would this work?
>
> Well I think that would work for my particular usage, however: If I'm
> reading between the lines of the Ansible pathname help texts, it appears
> that these settings can specify search paths, not a single file.
>
> In particular, the ANSIBLE_CFG_INVENTORY_FILE string is a comma-
> separated list. And, if ANSIBLE_CFG_FILE is an empty string, then there
> is a default set of locations /outside of/ the CWD that Ansible searches
> for a configuration.
That case will never happen, as we will ensure our sandbox var is always
defined (either with O=, or with PWD) and therefore the location of the kdevops
artifacts (.config, ansible.cfg, inventory, etc). That should preserve the
current functionality while also allowing others to generate kdevops artifacts
into separate directories.
>
> I'm not against your suggestion of specifying a sandbox pathname at all;
> that would be a good UX simplification. There are these details, though,
> and I don't have any suggestions about that at the moment.
Great! And agreed. Even if my assessment above is wrong, I don't see any major
blockers.
prev parent reply other threads:[~2025-09-01 17:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 20:28 [RFC PATCH 0/2] Set TOPDIR at run time Chuck Lever
2025-08-28 20:28 ` [RFC PATCH 1/2] Set TOPDIR_PATH and generate its sha256sum " Chuck Lever
2025-08-29 11:19 ` Luis Chamberlain
2025-08-29 13:38 ` Chuck Lever
2025-09-01 11:29 ` Daniel Gomez
2025-08-28 20:28 ` [RFC PATCH 2/2] ansible.cfg: generate an ansible.cfg file in TOPDIR Chuck Lever
2025-08-29 11:23 ` Luis Chamberlain
2025-08-29 13:39 ` Chuck Lever
2025-08-29 16:59 ` Luis Chamberlain
2025-09-01 12:00 ` Daniel Gomez
2025-09-01 15:03 ` Chuck Lever
2025-09-01 17:07 ` Daniel Gomez [this message]
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=d206bff7-9779-470a-beb7-e3c72de30b2b@kernel.org \
--to=da.gomez@kernel.org \
--cc=cel@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=kdevops@lists.linux.dev \
/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