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

Reply via email to