How to route execution to specific operators?

[ericlacher]

Hi Community

This is based on a discussion which started here.
I am going to set up a synapse kubernetes deployment, which will have multiple operators running on different node(pool)s (using the spec.selector feature as proposed by @cdavernas).
The expectation would be, that the spawned runners would then run on the very same node as the operator.

However, what I do not understand is, how can I route execution of a certain workflow to a specific operator?
It seems at this point, it happens completely randomly.

I have (local docker)

• an operator "Foo" in namespace "Foo"
• a default operator in namespace "default"
• a workflow in namespace "default"

Running this workflow multiple times in the UI causes the execution happening on a randomly picked operator. When I trigger it multiple times after another (without changing anything on the deployment), it will run on "Foo" as well as "default".

So, what's the envisioned way to specify an operator taking up a specific workflow?

Thanks,
Eric

PS: not sure this is related, but I can see the reported errors from here as well.

[JBBianchi]

Hello @ericlacher ,

I'm not entirely sure, but one thing you could try is adding a label when creating the WorkflowInstance resource, with the key operator and the value set to the name of the operator you'd like to target. Unfortunately, this feature doesn't exist in the UI currently, you'll have to make the call to the API manually.

#...
metadata:
  labels:
    operator: your-operator-name
#...

I haven't tested this setup myself, so I’d be curious to hear if it works for you. 🤞

[ericlacher]

@JBBianchi thanks for your input. I just tested this:

POST /api/v1/workflow-instances

{
  ...
  "metadata": {
    ...
    "labels": {
      "operator": "default-operator.default"
    }
  }
  ...
}

which did not work. I then inspected the created raw instance and tried to set a label when using the endpoint:

{
  ...
  "metadata": {
    ...
    "labels": {
      "synapse.io/operator": "default-operator.default"
    }
  }
  ...
}

also without success. I also tried different naming schemes for keys and values, but nothing worked.

[ericlacher]

...however, I now came across this code, and it indicates it should work as you described.

[ericlacher]

@cdavernas are these lines doing what they should?

• https://github.com/serverlessworkflow/synapse/blob/main/src/operator/Synapse.Operator/Services/WorkflowInstanceController.cs#L90
• https://github.com/serverlessworkflow/synapse/blob/main/src/operator/Synapse.Operator/Services/WorkflowInstanceController.cs#L115
• https://github.com/serverlessworkflow/synapse/blob/main/src/operator/Synapse.Operator/Services/WorkflowController.cs#L98
• https://github.com/serverlessworkflow/synapse/blob/main/src/operator/Synapse.Operator/Services/WorkflowController.cs#L123

E.g. on the claim method in WorkflowInstanceController we have

if (resource.Metadata.Labels != null && resource.Metadata.Labels.TryGetValue(SynapseDefaults.Resources.Labels.Operator, out var operatorQualifiedName) && operatorQualifiedName == this.Operator.Resource.GetQualifiedName()) return true;

Without knowing the details of this code, I would've assumed we want to avoid claiming, if there's a mismatch, so rather having

if (resource.Metadata.Labels != null && resource.Metadata.Labels.TryGetValue(SynapseDefaults.Resources.Labels.Operator, out var operatorQualifiedName) && operatorQualifiedName != this.Operator.Resource.GetQualifiedName()) return false;

(note != instead of == and true -> false)