openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michele Sciabarra" <mich...@sciabarra.com>
Subject Re: A plan to (re) implement OpenWhisk on top of Knative
Date Fri, 24 May 2019 15:47:47 GMT
I am taking all the suggestions and trying to setup a first implementation.


-- 
  Michele Sciabarra
  michele@sciabarra.com

----- Original message -----
From: James Thomas <jthomas.uk@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 <markusthoemmes@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

Mime
View raw message