openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <>
Subject Re: A plan to (re) implement OpenWhisk on top of Knative
Date Sun, 19 May 2019 21:53:17 GMT
Hi Michele,

thank you for the detailed writeup. A few thoughts inline:

Am So., 19. Mai 2019 um 19:00 Uhr schrieb Michele Sciabarra <>:

> 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.

Does this tie into the work that Matt was doing to the runtimes to make
them runnable on Knative? Is this lined up with that at all?

> 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.

Why not build this into "wsk" itself? The Azure Functions CLI as an example
supports multiple deployment types like this in one CLI.

> 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.

Why specifying Gloo here? Do you need anything specific from Gloo itself?
If not I'd propose to just keep it on a Knative Serving API surface level.

> 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

This feels like a fairly heavyweight process, we should be able to come up
with a way to circumvent zipping entirely. Maybe the runtime can detect
that the unzipped content is already there and skip the unzip step?

I'm fairly hesitant on the usage of a ConfigMap for storing the action
code. It's all stored in the in-cluster etcd instance and it has a limit of
1M. This is at most a stop-gap solution to provide a PoC I think. Any ideas
on how to "productize" this?

> At this point you can run the action. ActionLoop will be extended to
> support invocations in the format
> "/v1/namespaces/namespace/actions/package/action".

Why bother reimplementing this exact path? To obtain API compatibility with
OpenWhisk as it is today?

> It will do all the decoding required to invoke the action with the
> expected paramenters (straight invocation thrhoug the actinloop protocol,
> not proxies).

Does this mean moving all of the Controller's "smartness" about incoming
and outgoing HTTP requests (see the whole WebActions for example)?

> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message