** Description changed: + [Impact] + apscheduler’s get_next_run_time() function expects the value to be of type float. + However, SQLAlchemy’s scalar() may return a decimal.Decimal instead. + In that case, apscheduler raises a TypeError. + + The issue is addressed by the following patch in Watcher, which explicitly handles the type conversion. + This fix was merged starting with the 2024.2 release, so releases prior to 2024.1 do not include it. + + From e24cf31b608e92d9efe377662fba63887860c0c9 Mon Sep 17 00:00:00 2001 + From: Takashi Kajinami <[email protected]> + Date: Wed, 8 May 2024 15:24:52 +0900 + Subject: [PATCH] SQLAlchemy 2.0: Omnibus fixes patch + + This was originally five patches, but they are all needed to pass + any of the test jobs now, so they have been squashed into one: + + Co-Authored-By: Dan Smith ([email protected]) + + First: + + The autoload argument was removed[1] in SQLAlchemy and only + the autoload_with argument should be passed. + + The autoload argument is set according to the autoload_with argument + automatically even in SQLAlchemy 1.x[2] so is not at all needed. + + [1] https://github.com/sqlalchemy/sqlalchemy/commit/c932123bacad9bf047d160b85e3f95d396c513ae + [2] https://github.com/sqlalchemy/sqlalchemy/commit/ad8f921e969b6f735dc8e08d882c961dde78f2b1 + + Second: + + Remove _warn_on_bytestring for newer SA, AFAICT, this flag has been + removed from SQLAlchemy and that is why watcher-db-manage fails to + initialize the DB for me on jammy. This migration was passing the + default value (=False) anyway, so I assume this is the right "fix". + + Third: + + Fix joinedload passing string attribute names + + Fourth: + + Fix engine.select pattern to use begin() per the migration guide. + + Fifth: + + Override the apscheduler get_next_run_time() which appears to be + trivially not compatible with SQLAlchemy 2.0 because of a return type + from scalar(). + + Change-Id: I000e5e78f97f82ed4ea64d42f1c38354c3252e08 + + + [Test Case] + 1. deploy openstack env with watcher. ( based on juju ) + 2. openstack optimize audit create -t CONTINUOUS --interval 60 --goal dummy --strategy dummy --name test-audit + 3. juju ssh watcher/0 -- sudo systemctl restart watcher-decision-engine + 4. You may see error msg like below. + - Dec 16 06:15:45 node-15 watcher-decision-engine[88884]: TypeError: 'decimal.Decimal' object cannot be interpreted as an integer + + [Where problems could occur] + TBD + - tested Noble caracal, but need to test older versions. + + [Others] + + =original description= + Kolla-Ansible: 2023.2 Ubuntu 22.04.5 LTS I have a fresh installation in a three-node testing environment with Watcher enabled (deployed via Kolla Ansible). When creating a continuous audit, the watcher_engine container logs the following traceback: Exception in thread APScheduler: Traceback (most recent call last): - File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner - self.run() - File "/usr/lib/python3.10/threading.py", line 953, in run - self._target(*self._args, **self._kwargs) - File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/schedulers/blocking.py", line 32, in _main_loop - wait_seconds = self._process_jobs() - File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/schedulers/base.py", line 1005, in _process_jobs - jobstore_next_run_time = jobstore.get_next_run_time() - File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/jobstores/sqlalchemy.py", line 86, in get_next_run_time - return utc_timestamp_to_datetime(next_run_time) - File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/util.py", line 179, in utc_timestamp_to_datetime - return datetime.fromtimestamp(timestamp, utc) + File "/usr/lib/python3.10/threading.py", line 1016, in _bootstrap_inner + self.run() + File "/usr/lib/python3.10/threading.py", line 953, in run + self._target(*self._args, **self._kwargs) + File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/schedulers/blocking.py", line 32, in _main_loop + wait_seconds = self._process_jobs() + File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/schedulers/base.py", line 1005, in _process_jobs + jobstore_next_run_time = jobstore.get_next_run_time() + File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/jobstores/sqlalchemy.py", line 86, in get_next_run_time + return utc_timestamp_to_datetime(next_run_time) + File "/var/lib/kolla/venv/lib/python3.10/site-packages/apscheduler/util.py", line 179, in utc_timestamp_to_datetime + return datetime.fromtimestamp(timestamp, utc) TypeError: 'decimal.Decimal' object cannot be interpreted as an integer Source: https://github.com/agronholm/apscheduler/blob/be291699755e58ff398f90b5e71bff1e163df1db/apscheduler/jobstores/sqlalchemy.py#L85 For some reason, this line retrieves a decimal.Decimal, even though there’s no explicit configuration for float columns to default to asdecimal=False. This behavior aligns with the note by danms in the following commit: https://opendev.org/openstack/watcher/commit/d6f169197efc5b4f6c8a2e6bc38177b0641ca05c But danms assumes SQLAlchemy 2.0 stuff, which definetly isn't in my case. I also tested minimal Python scripts within the container to verify whether the issue is related to the versions of APScheduler (3.10.1) or SQLAlchemy (1.4.41), but I was unable to reproduce the problem. In those tests, float values were correctly returned from float-type columns.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2108994 Title: apscheduler retrieving decimal.Decimal via sqlalchemy To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2108994/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
