...
The general goal of this prototype is to use Knative for as much of the implementation as possible. Right now there are two primary components to the prototype: OpenWhisk-compatible client API This is implemented as a small Golang server with large parts autogenerated from the upstream OpenWhisk OpenAPI spec. Existing OpenWhisk clients communicate with this API which translates all OpenWhisk API calls into the appropriate Kubernets and Knative API calls. It is tested by running the existing OpenWhisk API test suite against this new server. Many tests do not pass yet, and some may require slight changes to the test suite to be able to pass long-term. The goal is to use the OpenWhisk API test suite to validate compatibility and eventually document any known incompatibilities. OpenWhisk-compatible runtime image shim This is implemented as a small Golang server that gets bundled into repackaged container images for each OpenWhisk action kind. Knative expects to be able to POST events to the root path ("/") of running servers while OpenWhisk expects different semantics of an Invoker calling "/init" and "/run" of the action runtimes. This shim essentially acts like a mini-invoker, translating Knative event requests into ones the OpenWhisk runtimes expect. This does mean that OpenWhisk container actions (ie blackbox actions) and other custom runtime images won't work out of the box without adding this shim. It is a later goal of this prototype to explore using Knative Build to automatically add the shim into arbitrary container images but that has not been implemented yet. Event flow on Knative TODO: Describe how events flow through Knative and invoke OpenWhisk Actions. ... |