controller_roles.yml
In these files we configure the roles for automation controller.
we will probably do this on each environment separately, as the hostnames differ.
variables
The api is not clear on the structure to use, the role documentation is, so we give you the link to the role documentation:
group_vars/all/controller_roles.yml
Here we map the hub credentials for use to the organizations.
---
controller_roles_all: []
# organizations get access to the hub credentals, each new organization must be added here
- organizations:
- ORG_LNX
- ORG_INFRA
- ORG_WEB
credentials:
- Default_automation_hub_token_published
- Default_automation_hub_token_community
- Default_automation_hub_token_rh_certified
- Default_automation_hub_image_pull_secret
role: use
...
But you can already see that the variable name used here has the "_all" extension, so the variable will not be overridden as this is not quite a inventory.
Why we do this, will become clear in a moment.
group_vars/dev/controller_roles.yml
As we do not configure extra roles in development, this file is an empty set.
(We use the containerized setup version, so no need for roles).
---
controller_roles_dev:
# we match the instance_group to the organization
- teams:
- LDAP_MGT_Admins
- LDAP_MGT_Developers
- LDAP_MGT_Operators
instance_groups:
- ig_mgt
role: use
...
Here the variable has the "_dev" extension, so the variable will not be overridden.
group_vars/prod/controller_roles.yml
As we do not configure extra roles in prod, this file is an empty set.
---
controller_roles_prod: []
# No extra config exists
...
Here the variable has the "_prod" extension, so the variable will not be overridden.
When we run a pipeline for a certain environment, the inventory structure will provide us with 2 variables:
- controller_roles_all
- controller_roles_
We will merge these 2 variables into 1: controller_roles and feed this to the infra.aap_configuration.controller_roles role.