We are evaluating temporal and trying to see if this use case works.
Run two temporal clusters piped with kafka, both will be active at the same time. Workers of an app has to do dedicated activities in corresponding cluster.
Is this possible ? I get a feeling while reading the documentation that primarily multi cluster setup is for failover and not intended for being in active condition at same time.
You can easily have two separate namespaces where one is active in clusterA and the other in clusterB at the same time. It’s just that one namespace can only be active and mutate workflow execution in only one cluster at any given point in time.
Since we cannot mutate the workflow execution across clusters in a same namespace, and since workflow is confined to a namespace (<- my understanding), there cannot be any shared execution context by any means right ? Even a worker belong to a workflow in namespace A (cluster A) cannot start another workflow/activity in namespace B (cluster B) ?
If you register a namespace as Global Namespace, that means it will be replicated to all clusters in the configured list. Although the Global Namespace can only be active in one cluster, meaning we allow calls like Start/Signal workflow executions and dispatch WorkflowTask/ActivityTask in the active cluster, but you should still run workers for this namespace on all standby clusters. As in the case of failover to that cluster we will continue execution of your workflows from it and start dispatching tasks to workers polling in that cluster. We also have request forwarding so if you call Start/Signal on a standby cluster, Temporal automatically forward the call to current active cluster.
I’m not sure what you mean by shared execution context. Can you clarify?
We currently don’t support cross namespace calls for activity/child workflows for Global Namespace. But this feature is on our roadmap.
@samar But a workflow in one namespace can activate a workflow in another namespace, right? If the active cluster for the second namespace is different than for the first one, one can accomplish the same outcome, right?
@maxim Forgive the elementary question here but please define what you mean by “global domains”. I did not find that concept in your documentation. Are you using it as a synonym for “global namespaces”?
And so a GNS cannot call a NGNS. That would seem to make the NGNS flavor of rather limited use for 24/7 systems across multiple data centers. Any NGNS workflow would be stuck in its DC, it would seem.
I agree. This is one of the reasons we don’t encourage cross namespace calls at this point. And that global namespaces is still an experimental feature.
In the longer term, we will support a new mechanism for cross namespace communication that is multi-cluster friendly. But is not going to be child workflows or activities.