From: Chuck Lever <cel@kernel.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: kdevops@lists.linux.dev, Chuck Lever <chuck.lever@oracle.com>
Subject: Re: [RFC PATCH v1] Add an Ansible requirements.yml file
Date: Mon, 25 Aug 2025 10:16:35 -0400 [thread overview]
Message-ID: <89e2f424-6cc3-4d99-9468-d8d194ee0870@kernel.org> (raw)
In-Reply-To: <aKwhBaq6cRnFDVVm@bombadil.infradead.org>
On 8/25/25 4:38 AM, Luis Chamberlain wrote:
> On Sun, Aug 24, 2025 at 12:23:05PM -0400, Chuck Lever wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> Commit b90d89d27659 ("Switch to the cloud.terraform.terraform
>> module") introduced the use of the cloud.terraform module, and
>> commit 7ccb64834eeb ("guestfs: Replace scripts/destroy_guestfs.sh
>> with an Ansible playbook") introduced the use of the
>> community.libvirt module. It would be friendly if kdevops could
>> pull in the Ansible modules it needs transparently.
>>
>> The requirements.yml file is a manifest of Ansible collections that
>> the project needs to run. Installation of these collections is made
>> automatic by adding:
>>
>> ansible-galaxy install -r requirements.yml
>>
>> to the "make ansible_cfg" step. This mechanism can keep cached
>> versions of collections up to date, and can also constrain a
>> cached collection to a specific version, if that's needed.
>>
>> The initial file contains requirements I could find easily, and
>> should be updated over time as new collection dependencies are
>> introduced.
>>
>> See also:
>>
>> https://docs.ansible.com/ansible/latest/user_guide/collections_using.html
>>
>> Question: Can we assume that the Ansible controller has internet
>> access all the time?
>
> That's not really an issue at all, but what I learned using galaxy stuff
> was if we required *our* own stuff upstream on galaxy it was not worth
> it.
>
> Given you're only using external stuff, then that seems sensible to me.
Yes, only collections that are already in the Ansible galaxy.
Any missing collections are installed into the Ansible user's home
directory, so "sudo" is not needed.
Also, this mechanism seems smart enough to deal with collections that
are already installed in shared locations. It skips re-installing.
> But now given our ongoing dialog over how to ease the pain to make it
> easy to use kdevops for new folks, how would this be handled? Are we
> OK with the request to phone home out?
Exactly; phoning home is OK for my own use cases, but I can't answer
that for anyone else's.
--
Chuck Lever
prev parent reply other threads:[~2025-08-25 14:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-24 16:23 [RFC PATCH v1] Add an Ansible requirements.yml file Chuck Lever
2025-08-25 8:38 ` Luis Chamberlain
2025-08-25 12:03 ` Daniel Gomez
2025-08-25 14:16 ` Chuck Lever [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=89e2f424-6cc3-4d99-9468-d8d194ee0870@kernel.org \
--to=cel@kernel.org \
--cc=chuck.lever@oracle.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