You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a result, it's impossible (or at least, not obvious) to add workers to an existing cluster that need large amounts of space for file staging & temporary files.
The text was updated successfully, but these errors were encountered:
This is difficult. One use case for grow-cluster is to grow a cluster to a previous size, for example after all spot workers were wiped out during a price increase. One would expect the replacement nodes to attach to the existing volumes as opposed to creating new volumes. To support this naively, we'd have to ignore --ebs-volume-size for replacement nodes and only apply it to new nodes and hence new volumes. The more advanced way of solving this would be to "resize" the volumes before attaching them. That would be pretty involved. You'd have to copy the volume and grow the file system inside it. You could only grow, not shrink.
… and when I say "new node" I mean a node that doesn't replace a previously existing node. The correct definition is "an instance with a cluster ordinal that was never assigned to another instance in this cluster".
Actually, I wasn't thinking about existing disks/nodes, so perhaps the --ebs-volune-size option doesn't make sense. However, currently if you have two nodes with EBS volumes and want to use "grow-cluster" to add two more, the new nodes will not have EBS volumes attached. So maybe it should be configuring volumes based on the initial configuration when the cluster is created?
As a result, it's impossible (or at least, not obvious) to add workers to an existing cluster that need large amounts of space for file staging & temporary files.
The text was updated successfully, but these errors were encountered: