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 2C93E2A1B2 for ; Mon, 1 Sep 2025 17:07:31 +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=1756746452; cv=none; b=Mcgl0ARuAtWdwmpv/LgzyvjP6c6/8D36nS0ZxNFat4ptBzVX+MY6PwL4mWTBjeqme5Fg0nLKp1fd+svz9Jg3Z2ADuHrJwWJgu9quTLnGtLT79J0JezVTAnZ25fnzvTaLTq0aBp4DDuwaiYo725DD6yHzcQ798IGsLP79Z7LzrNs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756746452; c=relaxed/simple; bh=ipczJmC0Ydnawj/xONuFGJX8cGktph/Th1UQNRhHv1w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=K+S6/b1xRBz0Z48un4Fp2X7m7NqgAIPW4rfV4C8rkl9LkO/30DOl9WgHfdT+X61uT9L2U727bxqStmA2cpq8cBHwUZ+s5hY6Ics7/HJL3ujxgNWulAZu+sr0wzCeD+oUbdnMrkF8F7bVxdHZcZQYZpyaEi9Dys8rtqHToOda7iE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uTN6YzGN; 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="uTN6YzGN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7186C4CEF0; Mon, 1 Sep 2025 17:07:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756746451; bh=ipczJmC0Ydnawj/xONuFGJX8cGktph/Th1UQNRhHv1w=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=uTN6YzGNt1uw+hZ/+2FU/ba2FWrpYsJKpylNMvEMYQ7uM9SMAWEVrEnkEjnEjH93c tMf6A79eDA/JLt2JDq3J3aNKCRDkv76EspQm9KpcYMHfQwDE6T1YrU9dZirPswahid 7puGogJVFXE4E5bp71R625guiRDshGOG81mWCRK3AYZD1N1mHNXT9YzljXWFqSLYws s0cc6YgHLXJf2/Ue2x6oFLh+FPfEE2V1kgUBpUnzFpArUIOaBCJx/XurwK4SRSRblY lUupxZRsDct+Fg7ww9TEnuDJMvu0YI/F4BPxX93U3SnnkBx2VzWyJhfD4TMPVI4vVc c3y/LkDlRSC4w== Message-ID: Date: Mon, 1 Sep 2025 19:07:28 +0200 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: [RFC PATCH 2/2] ansible.cfg: generate an ansible.cfg file in TOPDIR To: Chuck Lever , kdevops@lists.linux.dev Cc: Chuck Lever References: <20250828202827.3253499-1-cel@kernel.org> <20250828202827.3253499-3-cel@kernel.org> <5f05bdbc-d13b-4e2f-829d-095a2df2a24c@kernel.org> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 >>> >>> 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.