Added start delay to StartActivityExecutionRequest#749
Closed
Added start delay to StartActivityExecutionRequest#749
Conversation
feature: introduce compute config Introduces a new `compute.v1` package of proto messages that house the various instructions and information needed by worker control plane controllers `temporal.api.compute.v1.ComputeConfig` has three fields, `task_queues`, `provider` and `scaler` that store the configuration information for the server-owned worker setup and how the worker control plane should treat worker lifecycle events (such as when no pollers exist for a task queue that has received a task). The `temporal.api.compute.v1.ComputeConfig.task_queues` field is a list of task queue name and task type tuples. When Temporal Server receives a task with any of these name+type combinations and finds no active pollers, it will trigger a launch of a server-owned Worker using the configuration information in the `provider` field. The `temporal.api.compute.v1.ComputeConfig.provider` field is of type `temporal.api.compute.v1.ComputeProvider`. This message is a simple wrapper around a blob of bytes that contains configuration settings for a worker control plane controller. The configuration settings for the worker control plane controller are specific to different compute providers. The first compute provider we are modeling is AWS Lambda, and the `ProviderDetailAWSLambda` message houses the ARN of the AWS Lambda Function to be invoked and an optional ARN of the IAM Role that should be assumed by a worker control plane controller when invoking the function. The `temporal.api.compute.v1.ComputeConfig.scaler` field is of type `temporal.api.compute.v1.ComputeScaler`. This message contains instructions for when the worker lifecycle controller should scale up or down the number of workers in a WorkerDeployment or WorkerDeploymentVersion. Adds a new field `compute_config` to `WorkerDeploymentInfo` and `WorkerDeploymentVersionInfo` that contains a `temporal.api.compute.v1.ComputeConfig` message. Both WorkerDeployment and WorkerDeploymentVersion have this field in order to handle versioned workers properly. For example, if the user wants to use PINNED temporal versioning, they will be creating a WorkerDeploymentVersion that is specific to, say, a qualified Lambda Function ARN. Therefore we need to place compute provider configuration on a WorkerDeploymentVersion in addition to WorkerDeployment. Adds three new gRPC API methods to WorkflowService: * `CreateWorkerDeployment` creates a new WorkerDeployment containing the supplied compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeployment's compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeploymentVersion's compute configuration. Signed-off-by: Jay Pipes <[email protected]> Signed-off-by: Jay Pipes <[email protected]>
* origin/master: Add Principal to the base HistoryEvent (#733)
…nfig and enable per-task-type compute providers (#731) **What changed?** * Enables validating, creating and updating compute providers at the worker deployment version level, as that is where it at the most basic belongs * Making the scaler config more flexible to allow for pluggable scalers * Allowing for different compute providers depending on task types and regions
|
Semgrep found 1 No explicit |
feature: introduce compute config Introduces a new `compute.v1` package of proto messages that house the various instructions and information needed by worker control plane controllers `temporal.api.compute.v1.ComputeConfig` has three fields, `task_queues`, `provider` and `scaler` that store the configuration information for the server-owned worker setup and how the worker control plane should treat worker lifecycle events (such as when no pollers exist for a task queue that has received a task). The `temporal.api.compute.v1.ComputeConfig.task_queues` field is a list of task queue name and task type tuples. When Temporal Server receives a task with any of these name+type combinations and finds no active pollers, it will trigger a launch of a server-owned Worker using the configuration information in the `provider` field. The `temporal.api.compute.v1.ComputeConfig.provider` field is of type `temporal.api.compute.v1.ComputeProvider`. This message is a simple wrapper around a blob of bytes that contains configuration settings for a worker control plane controller. The configuration settings for the worker control plane controller are specific to different compute providers. The first compute provider we are modeling is AWS Lambda, and the `ProviderDetailAWSLambda` message houses the ARN of the AWS Lambda Function to be invoked and an optional ARN of the IAM Role that should be assumed by a worker control plane controller when invoking the function. The `temporal.api.compute.v1.ComputeConfig.scaler` field is of type `temporal.api.compute.v1.ComputeScaler`. This message contains instructions for when the worker lifecycle controller should scale up or down the number of workers in a WorkerDeployment or WorkerDeploymentVersion. Adds a new field `compute_config` to `WorkerDeploymentInfo` and `WorkerDeploymentVersionInfo` that contains a `temporal.api.compute.v1.ComputeConfig` message. Both WorkerDeployment and WorkerDeploymentVersion have this field in order to handle versioned workers properly. For example, if the user wants to use PINNED temporal versioning, they will be creating a WorkerDeploymentVersion that is specific to, say, a qualified Lambda Function ARN. Therefore we need to place compute provider configuration on a WorkerDeploymentVersion in addition to WorkerDeployment. Adds three new gRPC API methods to WorkflowService: * `CreateWorkerDeployment` creates a new WorkerDeployment containing the supplied compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeployment's compute configuration. * `UpdateWorkerDeploymentComputeConfig` updates an existing WorkerDeploymentVersion's compute configuration. Signed-off-by: Jay Pipes <[email protected]> Signed-off-by: Jay Pipes <[email protected]>
…nfig and enable per-task-type compute providers (#731) **What changed?** * Enables validating, creating and updating compute providers at the worker deployment version level, as that is where it at the most basic belongs * Making the scaler config more flexible to allow for pluggable scalers * Allowing for different compute providers depending on task types and regions
…tzeng/start-delay
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed?
Added start delay to StartActivityExecutionRequest
Why?
We need this field to support start delay for standalone activities