Is your feature request related to a problem? Please describe.
Consider a workflow DSL that lets users define their own workflows inside the product. The workflow implementation that interprets this DSL uses two kinds of activities:
- Activities that perform heavy computation
- Activities that only make HTTP or DB calls
The different activity workers and the workflow worker should not live in the same pod, for a few reasons:
- Each activity worker type and the workflow worker has its own security policy /
ServiceAccount.
- If an activity container fails, it should not affect the workflow worker. When
containers share a pod, both contribute to whether the pod is considered healthy.
- They have different scaling factors
- ......
That said, a single release that covers all workers is usually desirable, except in specific cases.
Describe the solution you'd like
Let users set the Temporal deployment name explicitly instead of always auto-generating it. With an explicit name, users could run multiple WorkerDeployment resources that share the same temporal deployment.
There might be a better way or practice how to handle such cases
Additional context
Is your feature request related to a problem? Please describe.
Consider a workflow DSL that lets users define their own workflows inside the product. The workflow implementation that interprets this DSL uses two kinds of activities:
The different activity workers and the workflow worker should not live in the same pod, for a few reasons:
ServiceAccount.
containers share a pod, both contribute to whether the pod is considered healthy.
That said, a single release that covers all workers is usually desirable, except in specific cases.
Describe the solution you'd like
Let users set the Temporal deployment name explicitly instead of always auto-generating it. With an explicit name, users could run multiple WorkerDeployment resources that share the same temporal deployment.
There might be a better way or practice how to handle such cases
Additional context