What is a Cluster?
Clusters are a logical grouping for task runners. Using clusters, you can scope certain tasks to a specific group of task runners. Tasks, which are always submitted to a specific cluster, are only executed on task runners assigned to the same cluster.
Use clusters to organize task runners into logical groups, which can help with:
Even when using different clusters, task runners within the same cluster may still have different capabilities, such as different registered tasks. If multiple task runners have the same set of registered tasks, you can assign them to different clusters to target specific task runners for a particular job.
You can add task runners to a cluster by specifying the cluster’s slug when registering a task runner. Each task runner must always be assigned to a cluster.
Each team has a default cluster that is automatically created for them. This cluster is used when no cluster is specified when registering a task runner or submitting a job. This is useful when you are just getting started and don’t need to create any custom clusters yet.
Before registering a task runner or submitting a job, you must create a cluster. You can also list, fetch, and delete clusters as needed. The following sections explain how to do this.
To manage clusters, first instantiate a cluster client using the clusters
method in the workflows client.
To create a cluster, use the create
method on the cluster client and provide a name for the cluster.
Each cluster has a unique identifier, combining the cluster’s name and an automatically generated identifier. Use this slug to reference the cluster for other operations, like submitting a job or subtasks.
To list all available clusters, use the all
method:
To fetch a specific cluster, use the find
method and pass the cluster’s slug:
To delete a cluster, use the delete
method and pass the cluster’s slug:
When submitting a job, you need to specify which cluster the job’s root task should be executed on. This allows you to direct the job to a specific set of task runners. By default, all sub-tasks within a job are also submitted to the same cluster, but this can be overridden to submit sub-tasks to different clusters if needed. See the example below for a job that spans across multiple clusters.
This workflow requires at least two task runners to complete. One must be in the “testing” cluster, and the other must be in the “other-cluster” cluster.
If no task runners are available in the “other-cluster,” the task submitted to that cluster will remain queued until a task runner is available.
It won’t execute on a task runner in the “testing” cluster, even if the task runner has the DummyTask
registered.
What is a Cluster?
Clusters are a logical grouping for task runners. Using clusters, you can scope certain tasks to a specific group of task runners. Tasks, which are always submitted to a specific cluster, are only executed on task runners assigned to the same cluster.
Use clusters to organize task runners into logical groups, which can help with:
Even when using different clusters, task runners within the same cluster may still have different capabilities, such as different registered tasks. If multiple task runners have the same set of registered tasks, you can assign them to different clusters to target specific task runners for a particular job.
You can add task runners to a cluster by specifying the cluster’s slug when registering a task runner. Each task runner must always be assigned to a cluster.
Each team has a default cluster that is automatically created for them. This cluster is used when no cluster is specified when registering a task runner or submitting a job. This is useful when you are just getting started and don’t need to create any custom clusters yet.
Before registering a task runner or submitting a job, you must create a cluster. You can also list, fetch, and delete clusters as needed. The following sections explain how to do this.
To manage clusters, first instantiate a cluster client using the clusters
method in the workflows client.
To create a cluster, use the create
method on the cluster client and provide a name for the cluster.
Each cluster has a unique identifier, combining the cluster’s name and an automatically generated identifier. Use this slug to reference the cluster for other operations, like submitting a job or subtasks.
To list all available clusters, use the all
method:
To fetch a specific cluster, use the find
method and pass the cluster’s slug:
To delete a cluster, use the delete
method and pass the cluster’s slug:
When submitting a job, you need to specify which cluster the job’s root task should be executed on. This allows you to direct the job to a specific set of task runners. By default, all sub-tasks within a job are also submitted to the same cluster, but this can be overridden to submit sub-tasks to different clusters if needed. See the example below for a job that spans across multiple clusters.
This workflow requires at least two task runners to complete. One must be in the “testing” cluster, and the other must be in the “other-cluster” cluster.
If no task runners are available in the “other-cluster,” the task submitted to that cluster will remain queued until a task runner is available.
It won’t execute on a task runner in the “testing” cluster, even if the task runner has the DummyTask
registered.