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
Client.shutdown claims to close cluster, but doesn't #1085
Comments
I believe there should be a method to tear down the cluster from the client. "shutdown" seems like the best name for this, so I would go for option 2. "close" would be the same thing as what happens on del? |
I believe things would be less confusing if cluster-affecting methods would be named explicitly, such as Agreed to also have a separate |
I'm in favor of |
@eriknw are you still interested in working on this? |
Welp. I remember poking around at this, but I can't find my previous work. Oops. I doubt I'll be able to work on this this quarter. |
Ok then. This might be a candidate for a good first or second issue, if someone is happy to leave a comment outlining roughly what should be done. |
Hi there, any progress on this? |
There have been some related updates and today In [1]: from distributed import Client, LocalCluster
In [2]: cluster = LocalCluster()
In [3]: client = Client(cluster)
In [4]: cluster.status
Out[4]: <Status.running: 'running'>
In [5]: client.shutdown()
In [6]: cluster.status
Out[6]: <Status.closed: 'closed'> Closing as resolved, though we can reopen as needed |
Client.shutdown claims in its docstring to tear down the cluster. This isn't currently the case. It only closes its own connection. We can either
If we change only the docstring, then should we also add the shutdown functionality to the client?
If we change the behavior then should we also add a close method?
http://stackoverflow.com/questions/44021931/stopping-dask-ssh-created-scheduler-from-the-client-interface
The text was updated successfully, but these errors were encountered: