I have an idea for implementing a prototype of OpenWhisk on top of Knative.
My basic ideas are: do not use any proxy, forwarding or adapter: extend the runtime to support the REST call and expose them as ingress. And use a wrapper on top of `kubectl` to generate all the needed componennts. My goal is to have a functional work-alike of OpenWhisk built on top of Knative, using ActionLoop as a foundation. I will extend ActionLoop to support the required REST calls of OpenWhisk. I also want to create tool, I will call `wskn`. This tool will initially just a python script, a wrapper on top of `kubectl` as it will generate kubernetes descriptors. It will support initially just the the action creation and invocation, and only synchronous (blocking) behaviour, as all the request will go straight to the runtimes. Hopefully also a subset of `package` and `activation`. Again triggers, rules, asynchronous for later. The idea is that you will be able to create actions and web actions that can run existing OpenWhisk actions, at least those with blocking behaviour that run with ActionLoop (Go, Java, Python, PHP, Swift, Rust, Ruby, Crystal...) Implementation. ============== This is how I plan to implement it. At this stage I want to use just Knative Serving and Knative Build, using Gloo for the ingress part. I also plan to install a local Docker registry Kubernetes registry, so we do not have to use DockerHub for everything. All of this can be done with existing command line tools in a few minutes in any running Kubernetes deployment. When I create an action, it will use Knative build that will work roughly in this way: - create a configmap with the action code - build the actin using ActionLoop precompilation feature that will return a zip file including all the needed to run the action - create a new docker image extending the runtime with the new zip, using Kaanico - push the image in the local registry At this point you can run the action. ActionLoop will be extended to support invocations in the format "/v1/namespaces/namespace/actions/package/action". It will do all the decoding required to invoke the action with the expected paramenters (straight invocation thrhoug the actinloop protocol, not proxies). Each action will then be exposed using an ingress with its specific invocation path. If the community agrees with this plan, I would create a repo `incubator-openwhisk-knative` to work on it. Thoughts? -- Michele Sciabarra mich...@sciabarra.com