Schedule module: creating an excess task about community.proxysql

[markuman]

True. And update a scheduler task happens only when an id is provided.
But it would be helpful if we provide a proxysql_scheduler_info module to determine ids.

[markuman]

And update a scheduler task happens only when an id is provided.

or when a user defined it originally (is it possible to set it when creating the task?), they can manipulate tasks using those ids later

Yes, I think it is possible. I just wanted to point out, if the id is not provided, all we can do is creating a new scheduler task.
So idempotent behavior is only possible when the id is provided.

[akimrx]

So far, I've solved the problem by adding a task that will delete all the schedules before adding them, but this is a temporary crutch, and not a normal solution, as it seems to me.

- name: proxysql - clean proxysql scheduler
  community.mysql.mysql_query:
    login_user: "{{ proxysql.admin.user }}"
    login_password: "{{ proxysql.admin.password }}"
    login_host: 127.0.0.1
    login_port: "{{ proxysql.admin.listen.port.plain | int }}"
    query:
      - "DELETE FROM scheduler"
      - "SAVE SCHEDULER TO DISK"
  tags:
    - proxysql-scheduler

- name: proxysql - configure scheduler
  proxysql_scheduler:
    login_user: "{{ proxysql.admin.user }}"
    login_password: "{{ proxysql.admin.password }}"
    login_port: "{{ proxysql.admin.listen.port.plain | int }}"
    filename: "{{ proxysql.path.lib }}/{{ item.bin }}"
    interval_ms: "{{ item.interval }}"
...

[markuman]

proxysql_scheduler search for the entry with

SELECT count(*) AS `schedule_count`
               FROM scheduler
               WHERE active = %s
                 AND interval_ms = %s
                 AND filename = %s"""

so when you request the same task-parameters just with active: no, it won't find and create a new one.
the only option to solve this issue is, to treat only the filename column as a unique key. even if it is not. otherwise it is impossible to tell if you want to add a new schedule task or adjust the existing one.

current scheduler table looks like this

CREATE TABLE scheduler (
    id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
    active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
    interval_ms INTEGER CHECK (interval_ms>=100 AND interval_ms<=100000000) NOT NULL,
    filename VARCHAR NOT NULL,
    arg1 VARCHAR,
    arg2 VARCHAR,
    arg3 VARCHAR,
    arg4 VARCHAR,
    arg5 VARCHAR,
    comment VARCHAR NOT NULL DEFAULT '')

say you got this

ProxySQL> select * from scheduler;
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| id | active | interval_ms | filename                        | arg1      | arg2 | arg3 | arg4    | arg5                                | comment |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| 1  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | warning | /opt/log/proxysql/replica_check.log |         |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+

and request

- name: some scheduler task
  proxysql_scheduler:
    filename:  /opt/lib/proxysql/replica_check
    interval_ms: 5000
    arg1: "127.0.0.1"
    arg2: 7030
    arg3: 2
    arg4: error
    arg5:  /opt/log/proxysql/replica_check.log
    state: present
    active: yes
    load_to_runtime: true
    save_to_disk: true

it is undefined if you want a)

ProxySQL> select * from scheduler;
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| id | active | interval_ms | filename                        | arg1      | arg2 | arg3 | arg4    | arg5                                | comment |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| 1  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | error | /opt/log/proxysql/replica_check.log |         |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+

or b)

ProxySQL> select * from scheduler;
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| id | active | interval_ms | filename                        | arg1      | arg2 | arg3 | arg4    | arg5                                | comment |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| 1  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | warning | /opt/log/proxysql/replica_check.log |         |
| 2  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | error   | /opt/log/proxysql/replica_check.log |         |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+

the current implementation treats active, interval_ms and filename as one combined private key.

Another possibility is to abuse the comment column with some conventions....find task by comment that must be uniq.

Any other ideas or opinions about this? @akimrx @Andersson007

[Andersson007]

CC @bmildren

[Andersson007]

Can we:

1. add the id field (optional) as was suggested? I think it will break nothing backwards

[Andersson007]

or when a user defined it originally (is it possible to set it when creating the task?), they can manipulate tasks using those ids later

[Andersson007]

True. And update a scheduler task happens only when an id is provided.
But it would be helpful if we provide a proxysql_scheduler_info module to determine ids.

But it's always a good idea to have info modules. It's also possible to create one proxysql_info module like in mysql_info which will return all the information from the cluster. But I'm not against the separate modules as well

[Andersson007]

I'm personally in favor of one module like mysql_info

[Andersson007]

Yes, I think it is possible. I just wanted to point out, if the id is not provided, all we can do is creating a new scheduler task.
So idempotent behavior is only possible when the id is provided.

Yes and, imo, it should be reflected in the documentation

[markuman]

Do we still need a proxysql_scheduler_info module? Because proxysql_info exists since 1.2.0

    - name: Add a schedule
      community.proxysql.proxysql_scheduler:
        login_user: 'admin'
        login_password: 'admin'
        interval_ms: 1000
        filename: "/opt/maintenance.py"
        state: present
        load_to_runtime: False

    - name: readout
      community.proxysql.proxysql_info:
        login_user: admin
        login_password: admin
      register: proxysql_information

    - debug:
        var: proxysql_information.scheduler

results in

TASK [debug] ********************************************************************************************************************************************************************************************************************
ok: [proxysql] => {
    "proxysql_information.scheduler": [
        {
            "active": "1",
            "arg1": null,
            "arg2": null,
            "arg3": null,
            "arg4": null,
            "arg5": null,
            "comment": "",
            "filename": "/opt/maintenance.py",
            "id": "1",
            "interval_ms": "1000"
        }
    ]
}

So the only task here is to fix the module itself, and not to add a _info module.

[Andersson007]

So the only task here is to fix the module itself, and not to add a _info module.

Sounds very sensible to me

[markuman]

here we discussed the behaviour of adding or updating schedule tasks and decided to fallback to a new id parameter for updates.
So far so good.

Say now, we ended up here

ProxySQL> select * from scheduler;
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| id | active | interval_ms | filename                        | arg1      | arg2 | arg3 | arg4    | arg5                                | comment |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+
| 1  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | warning | /opt/log/proxysql/replica_check.log |         |
| 2  | 1      | 5000        | /opt/lib/proxysql/replica_check | 127.0.0.1 | 7030 | 2    | error   | /opt/log/proxysql/replica_check.log |         |
+----+--------+-------------+---------------------------------+-----------+------+------+---------+-------------------------------------+---------+

and we'll request (basically from the example section)

- name: remove scheduler task
  proxysql_scheduler:
    filename:  /opt/lib/proxysql/replica_check
    config_file: '~/proxysql.cnf'
    state: absent

Currently the module will fail because it found more than one rule. https://github.com/ansible-collections/community.proxysql/blob/main/plugins/modules/proxysql_scheduler.py#L391

To keep backwards compatiblity, we must create a 2nd absent logic.
id is mutually exclusive with all other parameters when state is absent.

And maybe we should think about to deprecate the current absentlogic, because it is very very limited.

[markuman]

id is mutually exclusive with all other parameters when state is absent.

is this possible?

[Andersson007]

id is mutually exclusive with all other parameters when state is absent.

is this possible?

1. yep, just with a condition if id and state != 'absent' then fail or even alternatively we can just mention in the option's doc that it's ignored otherwise and ignore instead of failing
2. deprecation of logic in case of its limitation sounds good. If we gonna do that, we should

• announce it now as a breaking change (that it's coming in release blahblah)
• publish the announcement as a part of changelog fragment of the following release
• create the breaking PR
• merge it before the next major release