Skip to content

Dask and Distributed Support #299

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

Closed
crepererum opened this issue Mar 20, 2019 · 5 comments
Closed

Dask and Distributed Support #299

crepererum opened this issue Mar 20, 2019 · 5 comments
Labels
Help wanted Extra attention is needed New Integration Integrating with a new framework or library

Comments

@crepererum
Copy link
Contributor

crepererum commented Mar 20, 2019

(continued from #291)

It would be nice if sentry would support dask and distributed. Namely, the following features should be supported:

  1. sentry sdk initialized on the client should be carried over to the workers
  2. flushing the event queue should work (e.g. on subprocess shutdown for local executors or on worker shutdown for distributed)

feel free to split this ticket into two if required

@untitaker untitaker added enhancement Help wanted Extra attention is needed New Integration Integrating with a new framework or library labels Mar 20, 2019
@untitaker
Copy link
Member

sentry sdk initialized on the client should be carried over to the workers

We don't support this for any task queue. I'm not sure if it's a good idea because I don't quite know how the implementation would work. We also don't transfer scopes from clients to workers.

@crepererum
Copy link
Contributor Author

We don't support this for any task queue. I'm not sure if it's a good idea because I don't quite know how the implementation would work. We also don't transfer scopes from clients to workers.

OK. Could than at least the integration add some context to the events emitted by the workers? (like computation ID or even which part of the computation graph is currently executed)

@untitaker
Copy link
Member

Sure. I don't want to discard the idea of carrying over scopes if it makes sense, but carrying over SDK config is probably not expected.

I'm open to all kinds of ideas, but they should be non-invasive in the sense that we shouldn't just add new arguments to a job just because we need them on the other machine.

@github-actions
Copy link

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!


"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

@antonpirker
Copy link
Member

Currently we do not have plans to support this, Sorry.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help wanted Extra attention is needed New Integration Integrating with a new framework or library
Projects
None yet
Development

No branches or pull requests

4 participants