openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <markusthoem...@apache.org>
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 <
michele@sciabarra.com>:

> 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
>   michele@sciabarra.com
>

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