Conversation
Because Nannies pass their config into worker through a separate `config=` argument, setting dask config environment variables with the Enviorn nanny plugin confusingly had no effect. Now, any dask-config environment variables work automatically (besides memory limit, which is still handled specially by Nanny).
jrbourbeau
left a comment
There was a problem hiding this comment.
Thanks @gjoseph92!
It looks like this behavior can happen with the Nanny, independent of the Environ plugin:
distributed/distributed/nanny.py
Lines 820 to 821 in 332f785
Updating in WorkerProcess._run seems like a more centralized place to put this type of logic.
Also, can you add a test which demonstrates things are working as expected? See, for example, distributed/tests/test_nanny.py::test_environment_variable_by_config
|
Sure, that makes sense to me. The interface for specifying config/environ to the Nanny seems a bit ambiguous, since there are a number of overlapping options ( There were no tests for the Environ plugin to begin with so I continued the trend :) I'll add them for the changes to Nanny itself though. |
|
Yeah, prioritization here can get tricky. I think there was a previous conversation around this, but I can't seem to find it. cc @jacobtomlinson who may have thoughts on this topic There's this existing tests which could serve as a good model distributed/distributed/tests/test_nanny.py Lines 601 to 611 in 2298861 |
🤦 because the plugin is in |
Because Nannies pass their config into worker through a separate
config=argument, setting dask config environment variables with the Enviorn nanny plugin confusingly had no effect. Now, any dask-config environment variables work automatically (besides memory limit, which is still handled specially by Nanny).black distributed/flake8 distributed/isort distributed