sync_plans role not idempotent

[myllynen]

This simple playbooks reports changed on every run (tested against Satellite 6.16):

---
- name: Configure Red Hat Satellite
  hosts: satellite
  become: true
  gather_facts: true
  vars:
    satellite_sync_plans:
      - name: Weekly Red Hat repository sync
        interval: weekly
        sync_date: 2022-01-01 02:02:00 UTC
        enabled: true
        products:
          - Red Hat Satellite Capsule
          - Red Hat Enterprise Linux for x86_64
  roles:
    - redhat.satellite.sync_plans

Since no passwords are involved here perhaps it would be possible to make this idempotent. Thanks.

[evgeni]

Can you post the --diff output? I bet it's the way the date is stored (iirc that recently changed)

[myllynen]

Here's the --diff output:

TASK [redhat.satellite.sync_plans : Create Sync Plans] ***************************************************************************************************************************************************************************************
Thursday 28 November 2024  17:17:33 +0200 (0:00:00.041)       0:00:00.041 ***** 
changed: [satellite.example.com] => (item={'name': 'Weekly Red Hat repository sync', 'interval': 'weekly', 'sync_date': '2022-01-01 02:02:00 UTC', 'enabled': True, 'products': ['Red Hat Satellite Capsule', 'Red Hat Enterprise Linux for x86_64']})

Here's also -v output just in case:

TASK [redhat.satellite.sync_plans : Create Sync Plans] ********************************************************************************************************************************************************************************[2/209]
Thursday 28 November 2024  17:18:26 +0200 (0:00:00.041)       0:00:00.041 *****                                                                                                                                                               
changed: [satellite.example.com] => (item={'name': 'Weekly Red Hat repository sync', 'interval': 'weekly', 'sync_date': '2022-01-01 02:02:00 UTC', 'enabled': True, 'products': ['Red Hat Satellite Capsule', 'Red Hat Enterprise Linux for x86_64']}) => 
    ansible_loop_var: item
    changed: true
    entity:
        sync_plans:
        -   created_at: 2024-11-27 16:40:59 UTC
            cron_expression: null
            description: null
            enabled: true
            foreman_tasks_recurring_logic_id: 10
            id: 1
            interval: weekly
            name: Weekly Red Hat repository sync
            next_sync: 2024-11-30 02:02:00 UTC
            organization_id: 1
            permissions:
                destroy_sync_plans: true
                edit_sync_plans: true
                view_sync_plans: true
            products:
            -   cp_id: '479'
                description: null
                id: 195
                label: Red_Hat_Enterprise_Linux_for_x86_64
                last_sync: null
                last_sync_words: null
                name: Red Hat Enterprise Linux for x86_64
                repository_count: 5
                sync_state: null
            -   cp_id: '269'
                description: null
                id: 274
                label: Red_Hat_Satellite_Capsule
                last_sync: null
                last_sync_words: null
                name: Red Hat Satellite Capsule
                repository_count: 1
                sync_state: null
            sync_date: 2022-01-01 02:02:00 +0000
            updated_at: 2024-11-27 16:40:59 UTC
        sync_plans/products:
        -   id: 1
            product_ids:
            - 274
            - 195
    item:
        enabled: true
        interval: weekly
        name: Weekly Red Hat repository sync
        products:
        - Red Hat Satellite Capsule
        - Red Hat Enterprise Linux for x86_64
        sync_date: 2022-01-01 02:02:00 UTC

[evgeni]

Can you try using 2022-01-01 02:02:00 +0000 in your playbook?

[myllynen]

Yes, that works, thanks!

[evgeni]

Should this become "compare dates as dates, not strings"?
But at the same time: I don't think we'd get to it anytime soon

[itcultus]

I tried the following data:

satellite_sync_plans:
  - name: Weekly Sync
    interval: weekly
    sync_date: "2024-12-02 01:00:00 EET"
    enabled: false
    products:
      - Red Hat Enterprise Linux for x86_64

I used +0200, +0200 also but in all cases I got "changed".
I understand the low priority though.

[evgeni]

@itcultus curious, can you show the output of your playbook with --diff -v? that will include the API representation of the date.

[itcultus]

  entity:
    sync_plans:
    - created_at: 2024-12-05 19:55:13 UTC
      cron_expression: null
      description: null
      enabled: false
      foreman_tasks_recurring_logic_id: 10
      id: 1
      interval: weekly
      name: Weekly Sync
      next_sync: null
      organization_id: 1
      permissions:
        destroy_sync_plans: true
        edit_sync_plans: true
        view_sync_plans: true
      products:
      - cp_id: '479'
        description: null
        id: 65
        label: Red_Hat_Enterprise_Linux_for_x86_64
        last_sync: null
        last_sync_words: null
        name: Red Hat Enterprise Linux for x86_64
        repository_count: 2
        sync_state: null
      sync_date: 2024-12-01 23:00:00 +0000
      updated_at: 2024-12-06 07:47:20 UTC
    sync_plans/products:
    - id: 1
      product_ids:
      - 65
  item:
    enabled: false
    interval: weekly
    name: Weekly Sync
    products:
    - Red Hat Enterprise Linux for x86_64
    sync_date: 2024-12-02 01:00:00+0200

From the output it looks like it before saving the sync plan, date is changed to UTC (by the module or Satellite itself) so, if I use UTC it will be OK.
Hm...

[evgeni]

Mhh, yeah, it seems it's saved/shown as UTC (+0000) by Satellite. The module just sees that all as strings (which is why this problem exists in the first place, otherwise the dates would compare as equal just fine).

[itcultus]

I just did a new run with the dates in UTC and it's OK now. Maybe an update to the documentation will be helpful.
BTW, this is on the latest Satellite 6.16.