Skip to content
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

Remove worker-template from dask-kubernetes config #163

Closed
jhamman opened this issue Jul 10, 2019 · 4 comments
Closed

Remove worker-template from dask-kubernetes config #163

jhamman opened this issue Jul 10, 2019 · 4 comments

Comments

@jhamman
Copy link
Member

jhamman commented Jul 10, 2019

I'd like to propose dask-kubernetes deprecate the current usage of worker-template and worker-template-path from the config file. I suggest this for a few reasons:

  • Specification of the full cli executable sequence is implemented as a template in other cluster managers. Typically (e.g. dask-jobqueue, dask-yarn), keys like cores, processes, and memory are provided to the Cluster constructor.
  • It is easy to end up with templates that have misaligned specifications (i.e. a user may edit dask's memory-limit without editing the resource requirements.

Here's an example of the default dask-kubernetes setup:

worker-template-path: null
worker-template: {}
# kind: Pod
# metadata:
# labels:
# foo: bar
# baz: quux
# spec:
# restartPolicy: Never
# containers:
# - image: daskdev/dask:latest
# args:
# - dask-worker
# - --nthreads
# - '2'
# - --no-bokeh
# - --memory-limit
# - 6GB
# - --death-timeout
# - '60'
# resources:
# limits:
# cpu: "1.75"
# memory: 6G
# requests:
# cpu: "1.75"
# memory: 6G

Ideally, we can switch to something more concise:

kubernetes:
  worker:
    cores: 2
    processes: 1
    memory: 6G
    image: daskdev/dask:latest

Where the template and pod spec can be created on the fly.

@mrocklin
Copy link
Member

From my perspective the challenge here is that it's hard to wrap up all of the options in a comprehensive way. Someone will come by with a more custom configuation that they'd like to use.

I think it'd be fine to have an alternate approach to construct a pod spec template, (this already exists in a utility function I think) but I think that there is a lot of value to being able to pass through a template.

@jacobtomlinson
Copy link
Member

I agree. I think it's important to be able to pass a full spec through for maximum flexibility and customization.

However I'm not opposed to also having a more convenient way to create specs like the one Joe proposes. This could even be the default in the config, but should be overridden by a full pod spec.

@jhamman
Copy link
Member Author

jhamman commented Jul 11, 2019

Okay, I think I agree with you both now. As @mrocklin says, there is already a utility function to do this so we just need to pass config options through.

@jacobtomlinson
Copy link
Member

The classic KubeCluster was removed in #890. All users will need to migrate to the Dask Operator. Closing.

@jacobtomlinson jacobtomlinson closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants