Duplicate handling with wildcard

[myllynen]

With large organizations it is helpful to split configurations and have users/teams, credentials/inventories, projects/templates, etc separately. All this works fine with the dispatch role + wildcard.

There seems to be just one corner case that causes issues, below is a minimal reproducer created from a larger real-world configuration. Being able to configure users/teams will obviously need the organization so it is defined in one place without controller-specific details. Elsewhere are settings related to the controller. This allows using them independently. However, using them all together the end result is as below.

---
- name: Configure Ansible Automation Platform
  hosts: localhost
  connection: local
  become: false
  gather_facts: false
  vars:
    aap_organizations_test_org:
      - name: Test Org
        description: Test organization
    aap_organizations_test_org_ctrl:
      - name: Test Org
        description: Test organization
        max_hosts: 10
  tasks:
    - name: Apply AAP configuration
      vars:
        dispatch_include_wildcard_vars: true
      ansible.builtin.include_role:
        name: infra.aap_configuration.dispatch

On a fresh AAP installation only, so not on later attempts, this leads to:

TASK [infra.aap_configuration.collect_async_status : Create/Update AAP Platform Organizations Test Org | Wait for finish the Organizations creation] ***
fatal: [localhost]: FAILED! => 
    ansible_job_id: j359820304464.1550
    attempts: 1
    changed: false
    finished: 1
    msg: '{''detail'': ''duplicate key value violates unique constraint "aap_gateway_api_organization_name_key"\nDETAIL:  Key
        (name)=(Test Org) already exists.''}'
...
TASK [infra.aap_configuration.collect_async_status : handle_error | Show error and stop execution] ********************
fatal: [localhost]: FAILED! => 
    changed: false
    msg: 'error: {''detail'': ''duplicate key value violates unique constraint "aap_gateway_api_organization_name_key"\nDETAIL:  Key
        (name)=(Test Org) already exists.''}'

I wonder if something could be done to prevent this other than at least initially avoiding the duplicated definition? That would allow full flexibility when configuring AAP either initially or later on, whether everything at one go or in a piecemeal fashion. Thanks.

[myllynen]

It might actually be easiest to use suitable file naming and then using the same variable name, that would avoid this issue in the first place but still allow all use cases. For example, in 01_users_teams.yml have the minimal organization definition to allow creating users and teams for it and then in 02_controller the more complete definition, this would override the minimal definition if read e.g. with include_vars.

I'll leave this ticket open in case you see a way to avoid the above issue with the example playbook, it might still be helpful, but given that there seems to be a relatively simple workaround I'm not sure how relevant it is. Thanks.

[djdanielsson]

I do plan to unique the wildcard lookup results but in your use case I would say they should split their config by org into different repos. But I still see some style of managing config that could have intentional duplicate objects that it would expect to be fixed before applying which is why I will add unique option soon

[myllynen]

Note that this example was specifically about a single org with split users/teams vs controller related definitions.

Unique might be fine but I'm not sure would it still allow the above "last definition wins" to allow for controlling it with filenaming convention? But again, this is really a corner case so let's keep the effort reasonable, I think it's just the aap_organizations which is even affected by this.

[myllynen]

Please disregard my more previous comment, I was confusing the part where variables are read prior using wildcards (e.g., with include_vars), that is what the "last definition wins" in my comment was referring to, so that is not affected by if wildcard uses unique somehow.