Hi Michele, thank you for the detailed writeup. A few thoughts inline:
Am So., 19. Mai 2019 um 19:00 Uhr schrieb Michele Sciabarra < mich...@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 > mich...@sciabarra.com >
