eda_controller_tokens.yml

In these files we configure the controller tokens that can be used in eda controller.
we will probably do this on each environment specific (DEV, TEST, ACCP and PROD).

variables

The api understands the following structure:

{
    "name": "",
    "description": "",
    "inputs": {},
    "injectors": {}
}

Below you can see examples of how this is used.

group_vars/all/eda_controller_tokens.yml

Here we see an example of the configuration for a controller token.

---
eda_controller_tokens_all: []

...

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/eda_controller_tokens.yml

As we do not configure extra controller_tokens in development, this file is an empty set.

---
eda_controller_tokens_dev: []

  - name: my_default_token
    description: my default user token
    token: DEV TOKEN_VALUE...

Here the variable has the "_dev" extension, so the variable will not be overridden.

group_vars/prod/eda_controller_tokens.yml

As we do not configure extra controller_tokens in prod, this file is an empty set.

---
eda_controller_tokens_prod: []

  - name: my_default_token
    description: my default user token
    token: PROD TOKEN_VALUE...

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: - eda_controller_tokens_all
- eda_controller_tokens_

We will merge these 2 variables into 1: eda_controller_tokens and feed this to the infra.aap_configuration.eda_controller_tokens role.

Back