Default structure

The default directory structure is almost the same as (if you read my 2.5 solution) the 2.5 structure, just the contents is different.

.
├── ansibe.cfg
├── group_vars
│   ├── all
│   │   └── yml-files
│   ├── dev
│   │   └── yml-files
│   └── prod
│       └── yml-files
├── host_vars
│   └── aap_dev
│       ├── aap_auth.yaml
│       └── aap_dev.yaml
├── templates
│   └── ansible.cfg.j2
├── inventory.yaml
├── main.yml
├── README.md
└── workarounds.yml

Shown above is the global structure of a repository in git that will hold my configuration. It holds some files and directories that contain certain data structures and will be explained later.
You'll see 3 directories under group_vars that resemble an inventory, and this is a correct assumption. It looks like an inventory, but not as we know it.
The group_vars now consists of 2 environments 'dev' and 'prod'. In the host_vars the prod is missing, this is intentional during development, so I can't target production even by accident.
This will be added once development has ended.

This is one repository with configurationas code for rhaap2.6, eventually there will be 3 repositories with base code and a extra repository for each team/organization that is enabled in rhaap2.6.
As this is a gitlab repository using a pipeline, something you don't see here, is the .gitlab-ci.yml, the pipeline is configured elsewhere as a security feature. This will be explaned also at a later time.

Default files

The files that will be present in all repositories are:

ansible.cfg.j2

This is the template of the ansible.cfg where you have defined the repositories to download your collections from while executing the pipeline to apply the configuration. Be advised that this must also be availlable in a recovery situation!
We create the file in the main playbook, so it will always be availlable:

# Since Ansible 2.12 (core):
# To generate an example config file (a "disabled" one with all default settings, commented out):
#               $ ansible-config init --disabled > ansible.cfg
#
# Also you can now have a more complete file by including existing plugins:
# ansible-config init --disabled -t all > ansible.cfg

# For previous versions of Ansible you can check for examples in the 'stable' branches of each version
# Note that this file was always incomplete  and lagging changes to configuration settings

# for example, for 2.9: https://github.com/ansible/ansible/blob/stable-2.9/examples/ansible.cfg
[galaxy]
server_list = community_repo, rh-certified_repo,published_repo,validated_repo
validate_certs=false
ignore_certs=true
galaxy_ignore_certs=true

[galaxy_server.community_repo]
url="https://{{ inventory_hostname }}/api/galaxy/content/community"
token="{{ ansible_token }}"

[galaxy_server.rh-certified_repo]
url="https://{{ inventory_hostname }}/api/galaxy/content/rh-certified"
token="{{ ansible_token }}"

[galaxy_server.published_repo]
url="https://{{ inventory_hostname }}/api/galaxy"
token="{{ ansible_token }}"

[galaxy_server.validated_repo]
url="https://{{ inventory_hostname }}/api/galaxy/content/validated"
token="{{ ansible_token }}"

inventory.yml

Is exactly what you think it is, an inventory for the pipeline.

main.yml

This is where the magic happens a ansible playbook that harnesses the configurationas code and applies all tricks to make it functional.

README.md

As all repositories, this one needs a readme of what is in here and what it does and how.

workarounds.yml

In this file the default dispatcher configuration of the infra.aap_configuration collection is overruled (the order was alphabeticly ) and not in the correct execution order.
for each of the configuration types, the content will be somewhat different. At least until all bugs are fixed in the community collections.

Until now nothing shocking, easy to follow.
This will change