ansible.cfg pathname setting

ansible.cfg pathname setting

[Chuck Lever]

Hi-

The new ansible.cfg pathname Kconfig setting is vexing me a bit.

I generate kdevops .config files in a git repo on one system for a bunch
of automated test runners on other systems, each of which have their own
home directory.

The new ansible.cfg arrangement means the anisble.cfg pathname that is
soldered into the .config by default is my home directory, not the home
directory of the test runner.

I can set the test runner's home directory in each individual .config
but that's kind of painful if I need to run the workflow by hand for
working out bugs. I would rather have kdevops just plop the ansible.cfg
file in TOPDIR, whatever that happens to be for the day.

But there doesn't seem to be a mechanism to do that. The help says:

	  This option lets you specify the path and filename for the Ansible
	  configuration file. If the specified file already exists, it will not
	  be overwritten. Otherwise, kdevops will generate one using the settings
	  defined in this Kconfig menu.

	  If this option is left undefined or set to an empty string, kdevops
	  will not generate any configuration file. In that case, Ansible will
	  fall back to its own search order to locate a config file:
	    1. The ANSIBLE_CONFIG environment variable (if set)
	    2. ./ansible.cfg (in the current working directory)
	    3. ~/.ansible.cfg (in the user's home directory)
	    4. /etc/ansible/ansible.cfg (system-wide default)

I thought then that I could leave the pathname blank, but that means
no ansible.cfg is used. So now the new inventory pathname is not
specified at all, and that makes "make bringup" crap out. In other
words, a blank pathname only works if you build your own ansible.cfg.

So one idea would be to add a Kconfig option that means "Use a sensible
default location for the ansible.cfg file, but please do create it with
the settings here in .config, and please do remove it when we're done."

I think the inventory pathname needs similar treatment.

Any opinions about this idea? I can build it if folks agree to it.


-- 
Chuck Lever

Re: ansible.cfg pathname setting

[Luis Chamberlain]

On Thu, Aug 28, 2025 at 12:41:08PM -0400, Chuck Lever wrote:
> Any opinions about this idea? I can build it if folks agree to it.

I tend to just run my own new make defconfig-foo in each directory for
each workload, so I have opinion on this, but it sounds like perhaps
a kconfig option is desirable, to perhaps opt-in to let it use current
working directory for the file? But if it was not generated then via
make then what would it use? Ie, if you're shaing a built .config to
other directories without making make then it sounds like a requirement
is to also share the generated ansible config?

  Luis

Re: ansible.cfg pathname setting

[Chuck Lever]

On 8/28/25 2:59 PM, Luis Chamberlain wrote:
> On Thu, Aug 28, 2025 at 12:41:08PM -0400, Chuck Lever wrote:
>> Any opinions about this idea? I can build it if folks agree to it.
> 
> I tend to just run my own new make defconfig-foo in each directory for
> each workload, so I have opinion on this, but it sounds like perhaps
> a kconfig option is desirable, to perhaps opt-in to let it use current
> working directory for the file?

That's the basic idea. It feels like that would work better "just out
of the shrinkwrap".


> But if it was not generated then via
> make then what would it use? Ie, if you're shaing a built .config to
> other directories without making make then it sounds like a requirement
> is to also share the generated ansible config?

I think that's what I would have to do: include both the .config and
an ansible.cfg in the kdevops branch pulled by each test runner.

That seems to break the idea that the whole configuration is managed
from .config.


-- 
Chuck Lever

Re: ansible.cfg pathname setting

[Luis Chamberlain]

On Thu, Aug 28, 2025 at 03:08:48PM -0400, Chuck Lever wrote:
> On 8/28/25 2:59 PM, Luis Chamberlain wrote:
> > On Thu, Aug 28, 2025 at 12:41:08PM -0400, Chuck Lever wrote:
> >> Any opinions about this idea? I can build it if folks agree to it.
> > 
> > I tend to just run my own new make defconfig-foo in each directory for
> > each workload, so I have opinion on this, but it sounds like perhaps
> > a kconfig option is desirable, to perhaps opt-in to let it use current
> > working directory for the file?
> 
> That's the basic idea. It feels like that would work better "just out
> of the shrinkwrap".
> 
> 
> > But if it was not generated then via
> > make then what would it use? Ie, if you're shaing a built .config to
> > other directories without making make then it sounds like a requirement
> > is to also share the generated ansible config?
> 
> I think that's what I would have to do: include both the .config and
> an ansible.cfg in the kdevops branch pulled by each test runner.
>
> That seems to break the idea that the whole configuration is managed
> from .config.

Well, ansible.cfg is generated by stuff you enabled, I think right, so
one option is that if you *do* opt in for that feature, and you didn't
want to copy both, it could be smart, and if that feature was enabled
but ansible.cfg is not found, it could re-generate it.

Thoughts?

  Luis

Re: ansible.cfg pathname setting

[Chuck Lever]

On 8/28/25 3:11 PM, Luis Chamberlain wrote:
> On Thu, Aug 28, 2025 at 03:08:48PM -0400, Chuck Lever wrote:
>> On 8/28/25 2:59 PM, Luis Chamberlain wrote:
>>> On Thu, Aug 28, 2025 at 12:41:08PM -0400, Chuck Lever wrote:
>>>> Any opinions about this idea? I can build it if folks agree to it.
>>>
>>> I tend to just run my own new make defconfig-foo in each directory for
>>> each workload, so I have opinion on this, but it sounds like perhaps
>>> a kconfig option is desirable, to perhaps opt-in to let it use current
>>> working directory for the file?
>>
>> That's the basic idea. It feels like that would work better "just out
>> of the shrinkwrap".
>>
>>
>>> But if it was not generated then via
>>> make then what would it use? Ie, if you're shaing a built .config to
>>> other directories without making make then it sounds like a requirement
>>> is to also share the generated ansible config?
>>
>> I think that's what I would have to do: include both the .config and
>> an ansible.cfg in the kdevops branch pulled by each test runner.
>>
>> That seems to break the idea that the whole configuration is managed
>> from .config.
> 
> Well, ansible.cfg is generated by stuff you enabled, I think right, so
> one option is that if you *do* opt in for that feature, and you didn't
> want to copy both, it could be smart, and if that feature was enabled
> but ansible.cfg is not found, it could re-generate it.
> 
> Thoughts?

Yes. I'll have a demonstrator patch to post in a few minutes ;-)


-- 
Chuck Lever