Enhancement: Ensure filetree_create disambiguates duplicate resources when creating Job Templates

[daleroux]

Is your feature request related to a problem? Please describe.
When using the infra.controller_configuration.filetree_create plugin to create Job Templates, the playbook fails if resources such as Inventories or Credentials exist with the same name across different Organizations.

For example, if two inventories named testdelete exist in different Organizations, the resulting Job Template creation fails with:

"msg": "Request to /api/controller/v2/inventories/?name=testdelete returned 2 items, expected 1"

This behavior is blocking customers during migration scenarios (e.g., from AAP 2.4 to 2.5) because could have duplicate resource names across Orgs, or the very same resource name for credentials of two different credential types.

Describe the solution you'd like
Update filetree_create to generate Job Templates in a way that disambiguates duplicate resources by scoping lookups using both name and organization (e.g., organization__name), or by supporting ID-based references.

using the ansible.controller.controller_api lookup to disambiguate resources

This should apply not only to Inventories, but also to Credentials, Projects, and any other resources a Job Template may reference.

Please align the solution so that it aligns with the solution in JIRA https://issues.redhat.com/browse/AAP-51311

Describe alternatives you've considered
N/A

Additional context
Related Bug: AAP-51311
The Certified Collection module (ansible.controller.job_template) has been updated to allow disambiguation via lookup.
The same enhancement is needed in the Validated Collection (infra.controller_configuration.filetree_create) so that customers using this path are not blocked.

[djdanielsson]

@ivarmu @silvinux @adonisgarciac

[ivarmu]

First of all, and to clarify some concepts, filetree_create is creating configuration files in the local filesystem, and not the objects at the AAP/Controller instance. By the other side, filetree_read only reads configuration files into memory so dispatch role can finally deploy each object at the AAP/Controller instance. So, the modules affected by this issue are the ones called from the dispatch role.

In general, I don't like asking to the API for the information I already have stored in local configuration files, so I'm more aligned with Chris and @djdanielsson. Adding a new field per each object with this problem is also a solution, but I'd prefer this to be transparent, given the Configuration files have all the information in the correct place.

Important

It's also important to remember that we are implementing Configuration as Code, so the code is our source of truth, in it's fullness, and because of that, our implementations shouldn't relieve in any API responses or object's IDs.