Manage application pod

[mhnvelu]

Hi,

I recently joined serverless workflow group and attended few meetings. I got to know about Synapse and exploring it.

As a Serverless Workflow Runtime, can Synapse itself manage the application pods on demand, execute the request and delete the pod?

I could see currently "operation" attribute accepts the Open API as its value. So, my understanding is Synapse expects the application pod providing this service should be already UP and Running. The service is not managed by Synapse.

My thought is can Synapse itself manage the application pods life cycle and handle the workflow as well?
Currently function type supports "rest, rpc, graphql, expression". Can a new value, for example, "pod" be added to existing function types. Then,

"type": "pod"
"operation": "https://petstore.swagger.io/v2/swagger.json#loginUser"
"metadata" : {
"podFile": "app.yaml"
}

where app.yaml is the k8s manifest file for the pod.
using this information, Synapse creates the Pod, executes the use case and deletes the Pod.

Can the function schema extended to support metadata such that it can hold additional information.

Thanks & Regards,
Mohan

[cdavernas]

Hello @mhnvelu,

So, my understanding is Synapse expects the application pod providing this service should be already UP and Running. The service is not managed by Synapse.

No, in the current version, Synapse does not manage dependent services, but I believe that could easily be done.

My thought is can Synapse itself manage the application pods life cycle and handle the workflow as well?
Currently function type supports "rest, rpc, graphql, expression". Can a new value, for example, "pod" be added to existing function types.

Well, that's the very good idea, actually. @tsurdilo, WDYT? Should we add that to the spec?

If so, why not adding as well bash support as well, as @JBBianchi suggested to me? We could then do the following:

- name: bashTest
  type: bash
  operation: greeter.exe
  arguments: '--greeting "hello, there"'

Can the function schema extended to support metadata such that it can hold additional information.

Metadata is supported out of the box, for functions too. However, in case we decide to offically support with the pod operation type, I think it'd be better to move the podFile property inside the functionDef itself.

[cdavernas]

@mhnvelu if you are still interested, please check out the latest version, which implements the v1.x.x of the Serverless Workflow DSL, which has been refactored from top to bottom and which now features tasks that can run containers 😉