Run Task - Implementation requirements

[k-jay-c]

I'm reading through the new version of the specification.

I've come across the Run Task. The specification dictates that these are the default tasks that the runtime must implement.

I believe the only mandatory task that should be supported is run.workflow. The implementation for the rest should be optional.

For our usecase - we have no need to allow running of containers, or scripts or provide access to shell. There are security considerations associated with all these options, and there are good reasons where the runtime may not want to expose these options to the users.

Thoughts?

[cdavernas]

For our usecase - we have no need to allow running of containers, or scripts or provide access to shell.

Running containers, shell commands and scripts must be a default feature because without those primitives, you are severely restricting use cases, such as a CI/CD pipeline.

I guess you could indicate that your runtime does not support those features, but it would break cross-compatibility.

Those tasks are a sine-qua-non requirement, not only because they enable SW to be full featured when compared to the technologies it aims to encompass, but also because they enable both custom tasks and extensions.

There are security considerations associated with all these options

There are IMHO absolutely no security considerations associated with those options, those considerations are associated to how you envision implementing them.

Just like in GitHub Workflow, such tasks should be containerized - like all others by the way - to ensure isolation and dismiss any and all security concerns.

[JBBianchi]

I agree with @cdavernas, running commands/scripts was a missing feature in the previous iteration of the specification. (We might need to polish the spec on what and how to run things, but that's another discussion.)

That being said, nothing prevents you from having a partial implementation of the spec as long as your users are informed that some features are not supported.

[ricardozanini]

Well, I need to third that. The run tasks are the core part of the DSL in order to fit the workflow use cases out there.

But, a few years ago I brought up a discussion about capability/implementation levels, where a runtime could fit into a certain level and to be fully cross-compatible, one should have to fit all the levels. Or, to be cross-compatible among runtimes within the same level.

It's more or less what Kubernetes Operator SDK does, which I found pretty interesting:

So imagine level 1 to be rest tasks only and tasks flow, level 2 to emit events, and so on. I believe it's worth the discussion and brainstorming what this means. This way we might embrace more implementations in the long run.

[k-jay-c]

Based on the replies above, there are various assumptions being made about the usecases in which Serverless Specification should be utilised - may be that stems from the respective domains or the companies you work for. For your use cases which you're primarily targeting, these features may well be a must.

Usecases I'm looking at do not need to utilise some of the "mandatory" functions. My ask is not to remove them, to make them optional. If your runtime supports it, great, you can execute usecases where you integrate with CI/CD using a shell command or script.

Some more questions on how you envision some of the run. functions to operate:

• run.container - where will these containers be spun up? On the instance where the runtime is executing? What if someone had a usecase to manage lifecycle of containers on a remote setup? And in my case - there is no concept of allowing someone to spin up containers - but the runtime must support it?
• run.shell - where is this shell running? I've seen example of serverless workflow runtime on Temporal - say you have a worker that's running - you'll be executing the shell on the environment where the worker is running? What if you want to execute on a remote server.
• run.script - are you mandating support for any specific languages? If not, how will you ensure compatibility between different runtimes if one runtime supports Javascript, and another Python? Who decides what must be supported

[cdavernas]

Based on the replies above, there are various assumptions being made about the usecases in which Serverless Specification should be utilised

Those are not assumptions. As said above, the point of Serverless Workflow is to abstract away (Cloud) server implementations. Said implementations all provide a way to run containers (though some in a more indirect fashion), so that's a feature we must have. Furthermore, it's a feature that has been asked for countless times over the years I have been a member of the spec.

For your use cases which you're primarily targeting, these features may well be a must.

We are designing a DSL, not trying to answer the needs of our specific use cases (even though we have a plethora of them).

Usecases I'm looking at do not need to utilise some of the "mandatory" functions.

The argument of you not needing said tasks is, at best, not compelling.

If your runtime supports it, great, you can execute usecases where you integrate with CI/CD using a shell command or script.

As said before, those tasks are ESSENTIAL in order to enable custom tasks and other features of the DSL. Plus, in the light or what @ricardozanini proposed, I dont see any reason why you'd request that we downsize requirements just to fit your use cases.

where will these containers be spun up? On the instance where the runtime is executing? What if someone had a usecase to manage lifecycle of containers on a remote setup?

That's IMHO irrelevant, as it's totally runtime dependent. Plus, I don't see any issue with spinning/managing containers on any setup, should they be local or remote.

where is this shell running?

Same answer than before: runtimes decide how/where they want to run stuff. However, we need to make sure behaviors are consistent accross implementations, and that's why we are discussing about ways to jail the environment, like in GitHub Workflows.

run.script - are you mandating support for any specific languages?

Yes, we are: javascript and python. Why? Because they are the most used/popular. We created #874 to address documentation.

---

To conclude, and as said above, nothing is forbidding you from not fully implementing the DSL, and cherry pick what features you expect. I am not, however, keen on downgrading the required features because you "see no use" to those, which are by the way trivial to implement.

[ricardozanini]

@k-jay-c what we are trying to say is that the DSL can be compelling for all sorts of use cases. The implementation I'm working on does not implement CI/CD use cases, but for example, Tekton or GHA might make good use of shell, container, and script.

It is the runtime's responsibility to implement these features securely. Feel free to raise discussions regarding how to approach these requirements.

Aside, from reinforcing what @cdavernas just said regarding you not fully implementing the DSL, we can start discussing capability levels so one will know beforehand what to expect and what features are available in any given runtime.