You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ad-hoc clusters are a bunch of machines that can be reached via ssh but otherwise do not have a batch scheduler or container orchestrator. Our approach in general for these situations is to create an executor for each node, with the workers launched via an SSH channel. Creating separate executors means that load-balancing across nodes will not work. This sort of situation is common in clouds and private clusters and the driving use-case is from DESC (@jchiang87).
We could prototype an ad-hoc provider that takes a list channels pointing to each of the available nodes like this :
* Adding the new ad-hoc provider
* Updating dfk to support executor scaling when multiple channels exist for ad-hoc
* Minor updates
* Adding an ad-hoc test
* Part 1 of fixes to Ben's comments
* Updating docstrings
* Fixing the script dir checks in dflow
* Removing min/max/init blocks as configurables
* Removing redundant options from test
* Removing redundant translate table and fixing spaces
* Minor future proofing
* Removing fstring
* Adding new least_loaded method to determine appropriate channels for manager restart
* Splitting out a helper to handle channel dir creation and other minor cleanups
* convert adhoc cluster test config to use AdHoc provider (#1302)
* convert adhoc cluster test config to use AdHoc provider
* fix flake8
* Removing redundant _roundrobin method
* Fixed two assign vs equality check issues
* Updating kill command with Ben's recommended string
* Removing wording around round-robin
Ad-hoc clusters are a bunch of machines that can be reached via ssh but otherwise do not have a batch scheduler or container orchestrator. Our approach in general for these situations is to create an executor for each node, with the workers launched via an SSH channel. Creating separate executors means that load-balancing across nodes will not work. This sort of situation is common in clouds and private clusters and the driving use-case is from DESC (@jchiang87).
We could prototype an ad-hoc provider that takes a list channels pointing to each of the available nodes like this :
The text was updated successfully, but these errors were encountered: