controller_schedules.yml

In these files we configure the schedules for automation controller.
we will probably do this on each environment separately, as the hostnames differ.

group_vars/all/controller_schedules.yml

Here we see an empty set for all.

---
controller_schedules_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_schedules.yml

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

---
controller_schedules_dev:
  - name: MGT Check development website
    description: Check the site for dead links
    unified_job_template: MGT_site_check
    rrule: "DTSTART:20260101T100000Z RRULE:FREQ=DAILY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR"
    extra_data:
      site_to_check: 'website.dev.lab:80'
      protocol: http
...

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

What we see here is a schedule for a site check playbook that runs every workday at 10:00 (UTC).
A schedule definition has the following parameters:
- name: The name for the scheduled task.
- description: A description of what this schedule does.
- unified_job_template: The name of the job_template to run, whithin this organization.
- rrule: The reoccurrence rule (iCal format) for this schudule.
- extra_data: variables and values to pass to the playbook.

Almost all is pretty straightforward, just the rrule can be somewhat challenging:
See: rrule basics

group_vars/prod/controller_schedules.yml

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

---
controller_schedules_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_schedules_all
- controller_schedules_

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

RRULE basics

A RRULE in the controller_schedules.yml can be quite complex to set up.
There is much documentation about this on the internet, just throw RRULE in a search engine and you will find lots of info. Here are a few examples to help you start:

A RRULE is comprised of a number of elements, separated by a colon (;).

First we start with the rule in the example given:
"DTSTART:20260101T100000Z RRULE:FREQ=DAILY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR"

• DTSTART
  The Date and Time the rule initially starts, given by:
  The date, written in the following format:
  Year: 4 digits
  Month: 2 digits
  Day: 2 digits
  A time separator (T), folowed by the time specification:
  Hour: 2 digits
  minute: 2 digits
  (Z) Use default timezone
• RRULE
  The reoccurence rule specification: FREQ=DAILY
  INTERVAL=1 BYDAY=MO,TU,WE,TH,FR

As this doesn't specify a timezone the schedule wil use the system default timezone.
This is not always what you want (could be UTC.. ).
So if we extend the definition with a timezone,it would be like this:

"DTSTART;TZID=Europe/Amsterdam:20260101T100000 RRULE:FREQ=DAILY;INTERVAL=1;BYDAY=MO,TU,WE,TH,FR"

Another example:

rrule: "DTSTART;TZID=Europe/Amsterdam:20250513T100000 RRULE:FREQ=MONTHLY;INTERVAL=1;BYDAY=SA;BYSETPOS=1"

The above rule will schedule a reoccurring job to run on the first saturday of every month.
The frequency is monthLY.
The BYDAY is Saturday.
The INTERVAL selects every month.
The BYSETPOS selects the first BYDAY occurrance in every month, so the first saturday.

Full specification

Back