Runtime resolver of function reference

[xiekeyang]

Current Status

@erwinvaneyk and I have made some discussion about the rule of function reference and auto resolving unspecific function runtime. This allows user to input an ambiguous runtime, like:

• run: hello is auto resolved to fission://default/hello;

• run: compose is auto resolved to internal://compose;

It is pluggable, we may add new runtime like http, as run: hello may be auto resolved to http://hello (maybe it is a uri not function name).

This brings up the benefit that we should not reject the requests API with unspecific runtime by abrupt way. This is similar to the default keyword in the fission-based tasks, which was confusing to users. Workflow added an alias body that is the same, but you can still use default. All documentation and examples use body, so that is what users will use unless they have legacy workflows.

However, this brings some potential defects:

• Workflow sets up the priority level(like internal-fission-http...) to resolve the unspecific runtime, and return one with high priority runtime. However we don't know the exact runtime user want, unless they input the real runtime word.

• Auto resolver cost some time to look for matched runtime according to function ID on each request. Actually it will slow down the response obviously for that general functions are small and fast. It becomes serious in high-concurrency.

Brief Idea:

With Workflow released, we will provide the docs, to explain the function reference syntax, runtime keyword, and list of internal functions. As same as new possible pluggable runtimes.

When inputing a function reference, I think user always know what they want exactly, and how to input the function reference. So I assume that the strict validation will not enhance the use difficulty unfriendly to customer.

What's more, I feel that the runtime property of between internal and fission are total different. Current resolve can handle some simple template. However for complex ones:

• Function definition in CNCF serverless white paper, customer has to input more segments such as tag, version, or ID, then he can call the exact function.

• With possible http runtime support, the run field should be a legal URI or URL.

For these possible extense, flexible template and regexp parser are definitely not enough. So we had better to decouple the resolve (maybe and invocation) flowing completely.

ping @erwinvaneyk