Dask config size limitation in EC2Cluster
See original GitHub issueIt seems there is a 16kb limit on the amount of user_data that can be passed to an EC2 instance when starting up.
We serialize the local Dask config and pass it to the scheduler and workers via the user_data.
Depending on what config the user has locally this can tip us over the limit and result in the AWS API rejecting the instance creation call.
botocore.exceptions.ClientError: An error occurred (InvalidParameterValue) when calling the RunInstances operation: User data is limited to 16384 bytes
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:11 (5 by maintainers)
Top Results From Across the Web
Amazon Web Services (AWS) - Dask Cloud Provider
By default a Dask security group will be created with ports 8786 and 8787 exposed to the internet. The instance filesystem size in...
Read more >Dask Cloud Provider Documentation
Each cluster manager in Dask Cloudprovider will require some configuration specific to the cloud services you wish.
Read more >Configuration - Dask documentation
The maximum size of a websocket frame to send through a comm. This is somewhat duplicative of distributed.comm.shard, but websockets often have much...
Read more >Cluster Resource Limits - Dask Gateway
ClusterConfig.cluster_max_cores : Maximum number of cores per cluster. c.ClusterConfig.cluster_max_memory : Maximum amount of memory per cluster.
Read more >Frequently Asked Questions - Dask.distributed
Instructions are here under the heading “User Level FD Limits”: ... The Dask Scheduler tracks the location and size of every intermediate value...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@jacobtomlinson - I see what mistake I made. You pointed me in the right direction. When I first saw this error, I found this ticket. In the same repl session, I tried passing in the security=False and saw this error. In a fresh session, if you start with security=False, this works! Your comment above about Restarting your Python process or notebook kernel will clear out any cached certs makes sense now.
Thank you!
We enabled
security=True
by default because other default behaviour can cause your cluster to be exposed to the internet. However, Dask is typically deployed withsecurity=False
and folks use network-level security to secure their clusters, so I’d push back against this not being a production-grade workaround. For example, on Kubernetes you would use a service like Istio to handle this at the network layer.I totally agree though this it’s an unpleasant workaround and if there is a strong desire by the community to resolve this then I’m all for it. Do you have thoughts on a long term solution?