controller_notifications.yml

In these files we configure the notifications for automation controller.
we will probably do this on production only, as we don't want mail from all environments.

group_vars/all/controller_notifications.yml

Here we see an empty set for all.

---
controller_notifications_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/controller_notifications.yml

As we do not configure extra notifications in development, this file is an empty set.
(We use the containerized setup version, so no need for notifications).

---
controller_notifications_dev: []
  # No extra config exists
...

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

group_vars/prod/controller_notifications.yml

As we only configure notifications in prod.

---
controller_notifications_prod:
  - name: deploy_notification
    organization: ORG_NEW
    notification_type: email
    messages: '{}'
    notification_configuration:
      host: <smtp-service-host>
      password: <token>
      port: <smtp-port>
      recipients:
        - <email address>
      sender: <sender_address>
      timeout: 30
      use_ssl: true
      use_tls: false
      username: <username>
...

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_notifications_all
- controller_notifications_

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

Back