Unify adaptive solutions between distributed and dask-gateway
- Dominant language
- Python
- Stars
- 148
- Forks
- 93
- PR merge metrics
- No merged PRs in 30d
Description
This is more of a question than an issue (my apologies). I would like to better understand the motivations behind the adaptive logic in dask_cli.py . Some of this seems to be redundant with the code in `distributed/deploy/adaptive*.py`. I suspect that there was a good reason why things in dask-gateway were designed differently, but I'm not seeing them yet.
@jcrist if you have time to add history here I would appreciate it.
The one difference/improvement I see is that with the system in dask-gateway all of closing/active/target are known at one time, rather than collected over time at different points. Is this why the split? Is this approach better? If so, are there reasons why it couldn't be done upstream?
Contributor guide
Assessment
This issue has not been assessed yet.