-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arq scheduler #20
Arq scheduler #20
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works well. I still get issues when the default job dir doesn't exist. Also, I have a question about the bartender mix
cli and the assignment of one vs multiple workers.
if not configs: | ||
raise ValueError("No destination found in config file using arq scheduler") | ||
|
||
asyncio.run(run_workers(configs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused here. Do you need a separate destination for each worker? And each arqscheduler can have only one worker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to hear that,
Each arqscheduler needs at least one worker., but multiple (on different machines) is used to handle more jobs running at the same time.
You can have multiple destinations, for example
destinations:
quick:
scheduler:
type: arq
redis_dsn: redis://localhost:6379
filesystem:
type: local
small:
scheduler:
type: arq
redis_dsn: redis://localhost:6379
queue: small
filesystem:
type: dirac
big:
scheduler:
type: arq
redis_dsn: redis://bartender.uu.nl:6379
queue: big
filesystem:
type: sftp
hostname: headnode.cluster.uu.nl
- quick, could have worker on same machine as bartender web service.
bartender perform --destination quick
- small, could have workers run on a grid machines
- big, could have workers on hpc cluster compute nodes.
While checking arq docs I saw it used some bad defaults, so I added max_jobs
and job_timeout
props to ArqSchedulerConfig.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should such an example be part of the docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you add more workers by passing the same scheduler address in different destinations? Would be good to add more documentation on the new configuration page in the docs, yes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when redis is on internet a strong password should be added and some firewall rules
The built-in arq job_timeout default was 5 minutes which is too short. Set it to 1 hour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reviewing, you have given me some nice improvements.
if not configs: | ||
raise ValueError("No destination found in config file using arq scheduler") | ||
|
||
asyncio.run(run_workers(configs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to hear that,
Each arqscheduler needs at least one worker., but multiple (on different machines) is used to handle more jobs running at the same time.
You can have multiple destinations, for example
destinations:
quick:
scheduler:
type: arq
redis_dsn: redis://localhost:6379
filesystem:
type: local
small:
scheduler:
type: arq
redis_dsn: redis://localhost:6379
queue: small
filesystem:
type: dirac
big:
scheduler:
type: arq
redis_dsn: redis://bartender.uu.nl:6379
queue: big
filesystem:
type: sftp
hostname: headnode.cluster.uu.nl
- quick, could have worker on same machine as bartender web service.
bartender perform --destination quick
- small, could have workers run on a grid machines
- big, could have workers on hpc cluster compute nodes.
While checking arq docs I saw it used some bad defaults, so I added max_jobs
and job_timeout
props to ArqSchedulerConfig.
if not configs: | ||
raise ValueError("No destination found in config file using arq scheduler") | ||
|
||
asyncio.run(run_workers(configs)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should such an example be part of the docs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for following up. It would be nice to add some more explanation to the new configuration docs page in from #49
As after merge with origin/main the file was inconsistent
Use https://arq-docs.helpmanual.io/ to create a scheduler that uses Redis as a queue and multiple workers (
bartender perform
cli).TODO:
bartender perform
subcommand for worker[ ] Add redis + workers to docker-composepostponed to Docker compose deployment with arq workers #30To test:
docker run --detach --publish 6379:6379 redis:7
bartender serve
bartender mix
Fixes #21
Should be merged after #17