A failure occurs when removing a template and schedule

[Rickmarges]

Summary

When removing a template and schedule from the configuration, a failure occurs when ran using the diff roles.

Issue Type

• Bug Report

Ansible, Collection, Controller details

ansible-core == 2.15.1
ansible.controller == 4.4.0
controller_configuration == 2.5.0

Ansible installation method: EE

OS / ENVIRONMENT

OpenShift deployment of Ansible Automation Platform

Desired Behavior

The template and schedule are removed without any errors.

Actual Behavior

Since the template and schedule have a 1-to-1 mapping, the schedule is already removed when removing a template.
However, when removing them both from the configuration, the diff roles sets state abesnt for both.
When trying to remove the schedule (after the removal of the template), the playbook gives an error.

Traceback (most recent call last):
  File "/home/runner/.ansible/tmp/ansible-tmp-1692086728.8765502-1391-103420097972476/AnsiballZ_schedule.py", line 107, in <module>
    _ansiballz_main()
  File "/home/runner/.ansible/tmp/ansible-tmp-1692086728.8765502-1391-103420097972476/AnsiballZ_schedule.py", line 99, in _ansiballz_main
    invoke_module(zipped_mod, temp_path, ANSIBALLZ_PARAMS)
  File "/home/runner/.ansible/tmp/ansible-tmp-1692086728.8765502-1391-103420097972476/AnsiballZ_schedule.py", line 47, in invoke_module
    runpy.run_module(mod_name='ansible_collections.ansible.controller.plugins.modules.schedule', init_globals=dict(_module_fqn='ansible_collections.ansible.controller.plugins.modules.schedule', _modlib_path=modlib_path),
  File "/usr/lib64/python3.9/runpy.py", line 225, in run_module
    return _run_module_code(code, init_globals, run_name, mod_spec)
  File "/usr/lib64/python3.9/runpy.py", line 97, in _run_module_code
    _run_code(code, mod_globals, init_globals,
  File "/usr/lib64/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/tmp/ansible_schedule_payload_azgtc0a2/ansible_schedule_payload.zip/ansible_collections/ansible/controller/plugins/modules/schedule.py", line 361, in <module>
  File "/tmp/ansible_schedule_payload_azgtc0a2/ansible_schedule_payload.zip/ansible_collections/ansible/controller/plugins/modules/schedule.py", line 266, in main
TypeError: 'NoneType' object is not subscriptable

STEPS TO REPRODUCE

    - name: include the diff roles
      ansible.builtin.include_role:
        name: infra.controller_configuration.object_diff
      vars:
        include_present_state: true
        controller_configuration_object_diff_tasks:
          - {name: job_templates, var: controller_templates, tags: job_templates}
          - {name: schedules, var: controller_schedules, tags: schedules}

    - name: include the configuration roles
      ansible.builtin.include_role:
        name: infra.controller_configuration.dispatch
      vars:
        controller_configuration_dispatcher_roles:
          - {role: job_templates, var: controller_templates, tags: job_templates}
          - {role: schedules, var: controller_schedules, tags: schedules}

First run (to create them):

controller_schedules:
  - name: Dummy Schedule
    unified_job_template: Dummy template
    rrule: "DTSTART;TZID=Europe/Amsterdam:20230317T090000 RRULE:INTERVAL=1;FREQ=HOURLY"

controller_templates:
  - name: Dummy template
    organization: Dummy
    job_type: run
    project: Dummy Project
    playbook: dummy_playbook.yml
    inventory: Local

Second run (to remove them):

controller_schedules: []

controller_templates: []

[sean-m-sullivan]

it's an order of operations, it has no way of knowing that you just removed a schedule from a template, or the entire template, It might be a module improvement to account for these, I would expect and have seen the same of a inventory source when either an inventory or a project is removed.

[adonisgarciac]

I agree @sean-m-sullivan, it's an order mistake. I think @Rickmarges should call dispatch role in reverse order (first schedule and then job_templates.

To avoid these kind of problems, you should change completely the order which is defined by default in the dispatch role: https://github.com/redhat-cop/controller_configuration/blob/devel/roles/dispatch/defaults/main.yml#L2

[Rickmarges]

@adonisgarciac I don't agree with you on that one. If you first execute the schedules before the templates, you'll run into en error during creation. Because you can't create a schedule for a template that doesn't exist.

Having said that, I believe it is something that should be changed in the schedule module to not give an error if the schedule and template don't exist.

[sean-m-sullivan]

this is similar to the org and galaxy credentials chicken and egg, but shedule should be run after everything it can schedule and it should just work.

[adonisgarciac]

Yes, that's it to the creation phase but you failure is during the remove phase (which has to be executed in the exactly reverse order of creation).

You'll not be able to launch the creation and deletion in the same call to dispatch, you have to do it separately.

[Rickmarges]

@adonisgarciac it actually is possible to do it at the same time. When using the include_present_state: true, the diff roles builds a list of present and absent state items. And then the dispatch is executed for both at the same time

[adonisgarciac]

Technically yes, but you'll face with the same problem you are facing in several object types (inventory/inventory_source, organizations/galaxy_credentials, credentials/credentials_type, etc..)

Roles within this collections are treated as single kind of object. I think is not a good idea to change this behavior. So, IMHO, the complexity should be in the playbook, not in the roles of the collection.

[sean-m-sullivan]

agreed, the roles are independent, its difficult to account for all possibilities like this. I am closing this case unless we find a better way to account for these.