Scheduled Script are not persistent

[dga-nagra]

Deployment Type

NetBox Cloud

NetBox Version

v4.0.8

Python Version

3.11

Steps to Reproduce

1. Create a netbox instance (on a VM, docker, ...) with external database & redis
2. Schedule a script
3. Delete the netbox instance (the whole VM/container/...)
4. Recreate a new netbox instance

=> The scheduled script are not scheduled anymore
NOTE: This is a common way of working with containers /working with hashicorp packer to create an deploy a new image.

Expected Behavior

The scripts' scheduling should be persistent, i.e. still work as long as the database & redis are kept.

• Apparently, the current system uses the crontab which is not ideal. It should rely on something else, like a redis feature
• Schedules should be a new model so we can create/edit/delete them easily. On Netbox startup, it should check this table and ensure that the scheduling is configured correctly (whatever the method used)

Observed Behavior

After re-creating the instance, the script are not scheduled anymore.

[jeremystretch]

Apparently, the current system uses the crontab which is not ideal.

This is incorrect. The only place NetBox relies on a cron job is for the housekeeping task, which has nothing to do with scheduled jobs.

It should rely on something else, like a redis feature

It does rely on Redis. Job data is stored in the database using the Job model and pending jobs are tracked in Redis queues. Queued tasks can be viewed under Admin > Background Tasks. These all persist across reboots or rebuilds of individual compute instances provided the Redis & PostgreSQL databases are not disrupted.

[dga-nagra]

Hi @jeremystretch, sorry for the delay, I missed your answer.
Thank you for responding. It is strange because we use the community's docker image with an elasticcache service from AWS. When the container is re-created, we don't see the schedule jobs run anymore, even though the elasticcache. From the PR that implemented the scheduled tasked mentioned using Cron jobs, this is why I came with this conclusion, sorry for that.

I will check that and come back to this discussion when I found the real reason.