[mistral][heat][watcher][aodh] croniter being abandoned
Hi everyone, It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA). https://pypi.org/project/croniter/#disclaimer The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency. While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it. -- Thierry Carrez (ttx)
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this. i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction. for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used. i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large impact but i have not looked at it closely. we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8... when it was last bump in the requirement file but we did not really reflect on its usage beyond that. ill bring it up in the next irc meeting too for visablity
On 12/02/2025 02:08, Sean Mooney wrote:
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this.
i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction.
for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used.
i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large
impact but i have not looked at it closely.
we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8...
when it was last bump in the requirement file but we did not really reflect on its usage beyond that.
ill bring it up in the next irc meeting too for visablity
by the way zuul has had a cronlike timer tirgger for a very long time. zuul delegate this to the |apschedulerlib which watcher is already using |https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/timer/crontrigge... quickly checking the watcher usage, we are just using it to calculate when the job should run next https://github.com/openstack/watcher/blob/master/watcher/decision_engine/aud... so we might just take a leaf out of zuul book adn see if we can leverage |apscheduler.triggers.cronto replace croniter at least in the short term. | |there implemtion appares to be mostly freestanding https://github.com/agronholm/apscheduler/tree/3.x/src/apscheduler/triggers/c... although it may not be exactly 1:1 compatible with ||croniter | |it does seam to have a ||from_crontab fucntion that returns a ||CronTrigger obejct when given a chron expression https://apscheduler.readthedocs.io/en/3.x/modules/triggers/cron.html#apsched... and based on the test code it looks promising https://github.com/agronholm/apscheduler/blob/master/tests/triggers/test_cro... | |so for any project that already has apscheduler as a dep that might be a good option. one word or warning, apscheduler is currently working on a majory 4.x release like the Sqlachmy to 2.0 change this will require a lot of work for projects to support. so i would not advise adding it as a dependency if its not already used. | |https://pypi.org/project/python-crontab/ would be another options its LGPL v3 which i belive is apche2 compatible however its not currently un global/upper constraits so it needs to be reviewed before any project starts using it. | |regards| |sean. | | |
I've not yet looked into details of usage in watcher, but one difference I found between croniter and CronTrigger in appscheduler is handling of the nonstandard predefined scheduling definitions such as @hourly. (croniter accept these format while appscheduler doesn't) Currently heat is using croniter to validate input for aodh/mistral resources which defines alarms or tasks executed according to the schedule described in the format. So we may first need an established solution in these projects so that we can import the same solution for validation. As Sean mentioned that appscheduler is already used in watcher but I'm hesitant to add it to heat, aodh and mistral due to the other things it may pulls such as asyncio. I'm currently inclined to keep our eyes in the on-going discussion and consider creating a fork (or using any new proposed such as [1]) as the fallback plan, given the fact that we may need a common own implementation to keep supporting the existing usage. [1] https://pypi.org/project/python-crontab/ On 2/12/25 11:36 AM, Sean Mooney wrote:
On 12/02/2025 02:08, Sean Mooney wrote:
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this.
i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction.
for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used.
i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large
impact but i have not looked at it closely.
we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8...
when it was last bump in the requirement file but we did not really reflect on its usage beyond that.
ill bring it up in the next irc meeting too for visablity
by the way zuul has had a cronlike timer tirgger for a very long time. zuul delegate this to the |apschedulerlib which watcher is already using |https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/timer/crontrigge...
quickly checking the watcher usage, we are just using it to calculate when the job should run next https://github.com/openstack/watcher/blob/master/watcher/decision_engine/aud...
so we might just take a leaf out of zuul book adn see if we can leverage |apscheduler.triggers.cronto replace croniter at least in the short term. |
|there implemtion appares to be mostly freestanding https://github.com/agronholm/apscheduler/tree/3.x/src/apscheduler/triggers/c... although it may not be exactly 1:1 compatible with ||croniter |
|it does seam to have a ||from_crontab fucntion that returns a ||CronTrigger obejct when given a chron expression https://apscheduler.readthedocs.io/en/3.x/modules/triggers/cron.html#apsched... and based on the test code it looks promising https://github.com/agronholm/apscheduler/blob/master/tests/triggers/test_cro... |
|so for any project that already has apscheduler as a dep that might be a good option. one word or warning, apscheduler is currently working on a majory 4.x release like the Sqlachmy to 2.0 change this will require a lot of work for projects to support. so i would not advise adding it as a dependency if its not already used. |
|https://pypi.org/project/python-crontab/ would be another options its LGPL v3 which i belive is apche2 compatible however its not currently un global/upper constraits so it needs to be reviewed before any project starts using it. |
|regards|
|sean. |
| |
Thank you Thierry, I reported that on mistral launchpad. Not sure we will be able to get rid of it easily. Regards, Arnaud On 18.02.25 - 18:44, Takashi Kajinami wrote:
I've not yet looked into details of usage in watcher, but one difference I found between croniter and CronTrigger in appscheduler is handling of the nonstandard predefined scheduling definitions such as @hourly. (croniter accept these format while appscheduler doesn't)
Currently heat is using croniter to validate input for aodh/mistral resources which defines alarms or tasks executed according to the schedule described in the format. So we may first need an established solution in these projects so that we can import the same solution for validation. As Sean mentioned that appscheduler is already used in watcher but I'm hesitant to add it to heat, aodh and mistral due to the other things it may pulls such as asyncio.
I'm currently inclined to keep our eyes in the on-going discussion and consider creating a fork (or using any new proposed such as [1]) as the fallback plan, given the fact that we may need a common own implementation to keep supporting the existing usage.
[1] https://pypi.org/project/python-crontab/
On 2/12/25 11:36 AM, Sean Mooney wrote:
On 12/02/2025 02:08, Sean Mooney wrote:
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this.
i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction.
for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used.
i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large
impact but i have not looked at it closely.
we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8...
when it was last bump in the requirement file but we did not really reflect on its usage beyond that.
ill bring it up in the next irc meeting too for visablity
by the way zuul has had a cronlike timer tirgger for a very long time. zuul delegate this to the |apschedulerlib which watcher is already using |https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/timer/crontrigge...
quickly checking the watcher usage, we are just using it to calculate when the job should run next https://github.com/openstack/watcher/blob/master/watcher/decision_engine/aud...
so we might just take a leaf out of zuul book adn see if we can leverage |apscheduler.triggers.cronto replace croniter at least in the short term. |
|there implemtion appares to be mostly freestanding https://github.com/agronholm/apscheduler/tree/3.x/src/apscheduler/triggers/c... although it may not be exactly 1:1 compatible with ||croniter |
|it does seam to have a ||from_crontab fucntion that returns a ||CronTrigger obejct when given a chron expression https://apscheduler.readthedocs.io/en/3.x/modules/triggers/cron.html#apsched... and based on the test code it looks promising https://github.com/agronholm/apscheduler/blob/master/tests/triggers/test_cro... |
|so for any project that already has apscheduler as a dep that might be a good option. one word or warning, apscheduler is currently working on a majory 4.x release like the Sqlachmy to 2.0 change this will require a lot of work for projects to support. so i would not advise adding it as a dependency if its not already used. |
|https://pypi.org/project/python-crontab/ would be another options its LGPL v3 which i belive is apche2 compatible however its not currently un global/upper constraits so it needs to be reviewed before any project starts using it. |
|regards|
|sean. |
| |
What if we vendorise croniter.py inside our source code? It seems, most of the code is inside one file [1] If we amend the header, we can keep the MIT licensing/authors info? Is it something that would be ok as a short term solution? [1] https://github.com/corpusops/croniter/blob/master/src/croniter/croniter.py Arnaud. On 24.02.25 - 15:28, Arnaud Morin wrote:
Thank you Thierry, I reported that on mistral launchpad. Not sure we will be able to get rid of it easily.
Regards, Arnaud
On 18.02.25 - 18:44, Takashi Kajinami wrote:
I've not yet looked into details of usage in watcher, but one difference I found between croniter and CronTrigger in appscheduler is handling of the nonstandard predefined scheduling definitions such as @hourly. (croniter accept these format while appscheduler doesn't)
Currently heat is using croniter to validate input for aodh/mistral resources which defines alarms or tasks executed according to the schedule described in the format. So we may first need an established solution in these projects so that we can import the same solution for validation. As Sean mentioned that appscheduler is already used in watcher but I'm hesitant to add it to heat, aodh and mistral due to the other things it may pulls such as asyncio.
I'm currently inclined to keep our eyes in the on-going discussion and consider creating a fork (or using any new proposed such as [1]) as the fallback plan, given the fact that we may need a common own implementation to keep supporting the existing usage.
[1] https://pypi.org/project/python-crontab/
On 2/12/25 11:36 AM, Sean Mooney wrote:
On 12/02/2025 02:08, Sean Mooney wrote:
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this.
i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction.
for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used.
i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large
impact but i have not looked at it closely.
we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8...
when it was last bump in the requirement file but we did not really reflect on its usage beyond that.
ill bring it up in the next irc meeting too for visablity
by the way zuul has had a cronlike timer tirgger for a very long time. zuul delegate this to the |apschedulerlib which watcher is already using |https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/timer/crontrigge...
quickly checking the watcher usage, we are just using it to calculate when the job should run next https://github.com/openstack/watcher/blob/master/watcher/decision_engine/aud...
so we might just take a leaf out of zuul book adn see if we can leverage |apscheduler.triggers.cronto replace croniter at least in the short term. |
|there implemtion appares to be mostly freestanding https://github.com/agronholm/apscheduler/tree/3.x/src/apscheduler/triggers/c... although it may not be exactly 1:1 compatible with ||croniter |
|it does seam to have a ||from_crontab fucntion that returns a ||CronTrigger obejct when given a chron expression https://apscheduler.readthedocs.io/en/3.x/modules/triggers/cron.html#apsched... and based on the test code it looks promising https://github.com/agronholm/apscheduler/blob/master/tests/triggers/test_cro... |
|so for any project that already has apscheduler as a dep that might be a good option. one word or warning, apscheduler is currently working on a majory 4.x release like the Sqlachmy to 2.0 change this will require a lot of work for projects to support. so i would not advise adding it as a dependency if its not already used. |
|https://pypi.org/project/python-crontab/ would be another options its LGPL v3 which i belive is apche2 compatible however its not currently un global/upper constraits so it needs to be reviewed before any project starts using it. |
|regards|
|sean. |
| |
On 25/02/2025 11:34, Arnaud Morin wrote:
What if we vendorise croniter.py inside our source code?
It seems, most of the code is inside one file [1] If we amend the header, we can keep the MIT licensing/authors info? Is it something that would be ok as a short term solution?
[1] https://github.com/corpusops/croniter/blob/master/src/croniter/croniter.py
if you were to do that i woudl put it in a seperate vendor/folder. that semi problematic inthat we will have many copies. it would be better to have this isn oslo somewhere but its too late to do that in 2025.1 we have not had time to work on this for watcher this release but we can see what we can do between now and RC1 failing that we will drop the dep early in 2025.2 and likely backport that to stable/*
Arnaud.
On 24.02.25 - 15:28, Arnaud Morin wrote:
Thank you Thierry, I reported that on mistral launchpad. Not sure we will be able to get rid of it easily.
Regards, Arnaud
On 18.02.25 - 18:44, Takashi Kajinami wrote:
I've not yet looked into details of usage in watcher, but one difference I found between croniter and CronTrigger in appscheduler is handling of the nonstandard predefined scheduling definitions such as @hourly. (croniter accept these format while appscheduler doesn't)
Currently heat is using croniter to validate input for aodh/mistral resources which defines alarms or tasks executed according to the schedule described in the format. So we may first need an established solution in these projects so that we can import the same solution for validation. As Sean mentioned that appscheduler is already used in watcher but I'm hesitant to add it to heat, aodh and mistral due to the other things it may pulls such as asyncio.
I'm currently inclined to keep our eyes in the on-going discussion and consider creating a fork (or using any new proposed such as [1]) as the fallback plan, given the fact that we may need a common own implementation to keep supporting the existing usage.
[1] https://pypi.org/project/python-crontab/
On 2/12/25 11:36 AM, Sean Mooney wrote:
On 12/02/2025 02:08, Sean Mooney wrote:
On 11/02/2025 13:35, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
thanks for highlighting this.
i have added to the https://etherpad.opendev.org/p/openstack-watcher-irc-meeting ether pad under the possible PTG topics section as part of tech debt reduction.
for 2025.1 it is proably too late to remove this dep but ill try and find time to review exactly how its used.
i belive it only use for the continuous audit to define effectively the execution schedule so it may be something we can remove or replace without a large
impact but i have not looked at it closely.
we had to make a trivial test only fix in novmeber https://github.com/openstack/watcher/commit/fbb290b2238e9e72054892e9ae6108a8...
when it was last bump in the requirement file but we did not really reflect on its usage beyond that.
ill bring it up in the next irc meeting too for visablity
by the way zuul has had a cronlike timer tirgger for a very long time. zuul delegate this to the |apschedulerlib which watcher is already using |https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/timer/crontrigge...
quickly checking the watcher usage, we are just using it to calculate when the job should run next https://github.com/openstack/watcher/blob/master/watcher/decision_engine/aud...
so we might just take a leaf out of zuul book adn see if we can leverage |apscheduler.triggers.cronto replace croniter at least in the short term. |
|there implemtion appares to be mostly freestanding https://github.com/agronholm/apscheduler/tree/3.x/src/apscheduler/triggers/c... although it may not be exactly 1:1 compatible with ||croniter |
|it does seam to have a ||from_crontab fucntion that returns a ||CronTrigger obejct when given a chron expression https://apscheduler.readthedocs.io/en/3.x/modules/triggers/cron.html#apsched... and based on the test code it looks promising https://github.com/agronholm/apscheduler/blob/master/tests/triggers/test_cro... |
|so for any project that already has apscheduler as a dep that might be a good option. one word or warning, apscheduler is currently working on a majory 4.x release like the Sqlachmy to 2.0 change this will require a lot of work for projects to support. so i would not advise adding it as a dependency if its not already used. |
|https://pypi.org/project/python-crontab/ would be another options its LGPL v3 which i belive is apche2 compatible however its not currently un global/upper constraits so it needs to be reviewed before any project starts using it. |
|regards|
|sean. |
| |
On Tue, Feb 11, 2025 at 7:06 PM Thierry Carrez <thierry@openstack.org> wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
Thanks for bringing this to our attention Thierry. We are dropping its usage in heat with https://review.opendev.org/c/openstack/heat/+/941314.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
-- Thierry Carrez (ttx)
-- Regards, Rabi Mishra
It seem that they agreed[1] with the solution to transfer the project to the Pallete project[2] (more precisely speaking, its community ecosystem). The Pallet project hosts some popular python libraries such as Flask, werkzeug and jinja which we already heavily depend on. While we can consider replacing croniter where it's not really required, I think we don't have to replace it really urgently at this moment. [1] https://github.com/pallets-eco/croniter/issues/144#issuecomment-2740882901 [2] https://palletsprojects.com/ On 2/11/25 10:35 PM, Thierry Carrez wrote:
Hi everyone,
It was brought to my attention that the croniter maintainer has decided to abandon his project, due to not wanting to deal with his perceived exposure to the EU Cyber-Resilience act (CRA).
https://pypi.org/project/croniter/#disclaimer
The maintainer indicates that you should no longer use it and it may be "unpublished" any time after March 15, 2025. Croniter is being used in at least Mistral, Heat, Watcher, and Aodh as a dependency.
While this is clearly an overreaction (the CRA only applies to "economic operators" putting "products with digital elements" on the market "in the course of a commercial activity"), we should probably prepare to migrate away from this dependency, or maintain a fork of it.
participants (5)
-
Arnaud Morin
-
Rabi Mishra
-
Sean Mooney
-
Takashi Kajinami
-
Thierry Carrez