Thanks for taking the time to do this POC Michele. I'm looking forward for learn about the cold-start times with KNative.
On Fri, May 24, 2019 at 8:48 AM Michele Sciabarra <mich...@sciabarra.com> wrote: > 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 >
