I am taking all the suggestions and trying to setup a first implementation.
-- Michele Sciabarra mich...@sciabarra.com ----- Original message ----- From: James Thomas <jthomas...@gmail.com> To: dev@openwhisk.apache.org Subject: Re: A plan to (re) implement OpenWhisk on top of Knative Date: Friday, May 24, 2019 5:39 PM On Mon, 20 May 2019 at 15:50, Markus Thömmes <markusthoem...@apache.org> wrote: > > Can we try to define what the desired end-goal is here? I'm a bit unclear > what resembling the OpenWhisk API actually buys us. > > To me, the desired end-state would be to run OpenWhisk actions as-is on a > Knative cluster (similar to OpenFaaS' and Azure's integration). There's no > good way for us to provide the full API without spinning up a control plane > and we can only handle so much via the CLI. So to me, the end-goal looks > like: > > 1. *wsk action create* actually doing all the pieces necessary to run a > piece of code on Knative. > 2. *wsk action invoke* doing some HTTP call under the hood to "invoke" that > action. The action should be reachable via a sensible URL. If we really > want to keep the API surface (as I said, I'm dubious here) we can also do > that via ingress level abstractions (like VirtualService). I've been spending a bit more time reading up on knative this week and agree with Markus' suggestions. In the short term, being able to run an OpenWhisk action on Knative with no changes to the action code is a good first step. I think the work Priti has done with others to make the Node.js runtime Knative compatible is a sensible step towards this. (https://github.com/apache/incubator-openwhisk-runtime-nodejs/pull/119) If we can utilise that approach with the actionloop runtimes - that'd be great. This means people can move (simple) OpenWhisk actions from a platform instance to knative with minimal changes. Having a defined build pipeline to produce docker images from action code seems like the next step... The user has to do this manually but it simplifies the process of building those images manually. The longer-term discussion is whether we allow people to use the existing OpenWhisk API (and tools) as a proxy for actions deployed on knative. This would means people can switch their clients (CLI) between a normal openwhisk instance and a knative-based one.. This would be similiar to how projects like Riff operate. Gloo does have some interesting concepts around "function level" routing that are building out that might be useful (https://gloo.solo.io/user_guides/cloud_function/) -- Regards, James Thomas
