From dev-return-4078-apmail-openwhisk-dev-archive=openwhisk.apache.org@openwhisk.apache.org Wed Jul 3 14:29:37 2019
Return-Path:
X-Original-To: apmail-openwhisk-dev-archive@minotaur.apache.org
Delivered-To: apmail-openwhisk-dev-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [207.244.88.153])
by minotaur.apache.org (Postfix) with SMTP id C380919C66
for ; Wed, 3 Jul 2019 14:29:35 +0000 (UTC)
Received: (qmail 63857 invoked by uid 500); 3 Jul 2019 14:29:34 -0000
Delivered-To: apmail-openwhisk-dev-archive@openwhisk.apache.org
Received: (qmail 63804 invoked by uid 500); 3 Jul 2019 14:29:34 -0000
Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@openwhisk.apache.org
Delivered-To: mailing list dev@openwhisk.apache.org
Received: (qmail 63791 invoked by uid 99); 3 Jul 2019 14:29:33 -0000
Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Jul 2019 14:29:33 +0000
Received: from localhost (localhost [127.0.0.1])
by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id DC96A180D89
for ; Wed, 3 Jul 2019 14:29:32 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=6.31
tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled
Authentication-Results: spamd3-us-west.apache.org (amavisd-new);
dkim=pass (1024-bit key) header.d=web.de
Received: from mx1-ec2-va.apache.org ([10.40.0.8])
by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024)
with ESMTP id d0cecJm8Qo4B for ;
Wed, 3 Jul 2019 14:29:30 +0000 (UTC)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=212.227.15.14; helo=mout.web.de; envelope-from=martin.henke@web.de; receiver=
Received: from mout.web.de (mout.web.de [212.227.15.14])
by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 0BE0DBC52B
for ; Wed, 3 Jul 2019 14:29:29 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de;
s=dbaedf251592; t=1562164163;
bh=87aKUDsgw6XxFNpAwi43CCo1QY4KAx8tqrvQaz39UhE=;
h=X-UI-Sender-Class:From:Subject:Date:To;
b=guBf2tiXBK5KashVBrXwqQtfwMIBRawSChAbD95r4wPZvQZjKcwT1LuMyWPCl2Ypr
Qc9S7FPmSooV+Uo1x+1+RZJRp1y95lwFzH4nkl23rudEA/pI9/vKPawH0q+kyXmXsy
mMhFmY4PTdTykmqlUih8Gc/GdK7gPSX/Cav1rA0I=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from dyn-9-152-98-179.boeblingen.de.ibm.com ([195.212.29.175]) by
smtp.web.de (mrweb003 [213.165.67.108]) with ESMTPSA (Nemesis) id
0LzKJV-1ie1v13hM9-014QD2 for ; Wed, 03 Jul 2019
16:29:22 +0200
From: Martin Henke
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: A plan to (re) implement OpenWhisk on top of Knative
Message-Id:
Date: Wed, 3 Jul 2019 16:29:22 +0200
To: dev@openwhisk.apache.org
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:yr18MxFnpxkPX8l79v1MxjHk6mcXHZ9TaAYZ2x4eqZvK5VHi3RH
9C1LUVGyAEwrZalr4JC/oRaQPOsCUFfFXuSmSKCfNMIJqjYkctKsPK8f/rnlGhGC0jBVfJy
MSN9rAPpvo0uAlRADkP736Yrk/T39pJyZZK8MmbDkUaLOBt4S8vfNP0Q91xFGI8eTAz8qLz
AYdQtyiX5qncIFOrOpXzQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:QiEJLZ621+U=:PRJHZbLvNI0eRFvPJcS7zM
V7Ebf5clYzBDSUoesHRusDk2jR7Km/Wf8j4QXgrnbG3sHu/d/59eYYupeWxkhcbj7cJLJgqqx
WXSIBX5wFnnl6EpIKCGyv8yo3QLMNSQxTAwkOQzHMBdJKeUOYj/E/4HoNZgGnwcp9B3HfXbme
aNWKiHC+TyDJ0YNy3/d5bnf6rLfkF3aetOW7iLz948H9HixcXJMtx6mSN4wNyaMFQ44vzXRrL
nuDjj94+/MuGnJvbWFg8nhOrSjv7yb1rxJEaxJ/V9TzwSB97jvQMrLjnAHpMuzeepzCjFslDT
UxO2aN5yZJm0h0W9yzC8UujWver5YF4R9Fe5+1/+T6Lsb1rmqPLawETEyGIwsFid184wbZh5U
xbgOuE0f2d7JQZOJg+k4n9CYsDRagWeshFdVJ2LsnmdVlST/9oMKpwC8TphyiWxi4DcElkvt3
/NwEtu48LCHDr7m8jZve5o040TM3STg5MAm7BlVrWHeP9iG5czFuMqGzCCC1xqEvKdmCsm3NW
vMYwWDPaQFWNrukC6sacNFzofdz8kXPTGF95F5LUsDGVb0QTGlId9DHWEy4ox785qnbu+juJ8
0OWeA1nfiIOVsr/Y6IaswSND11RWpr2hX8Xb3GLKhXXqbvEA+HEqOrs480pGqcF48JVGNXuya
+5QLSpTXOhYTPE2XLvAiYZFpyhpedLPUq8RKi8sQxuPEaeBkqbeGYzgFivv8XdU5FEomdnH2y
jX9uXyFzpOu8o+uvTqn+KJCC/VIoDQ41dhnQ3W3Jx505KNUNRtIHIZxwc867F3IVNuUufXc5E
ou92x1gvn/e9FKOs+NXxJho8XHWM3yJ+vQQK6I9f66LGxwBOzguAOUWVIoWErUsupI2c0F4zY
iIZhOCLnd723NPHgFwOvuEzmopcqmhd9QQcUuWlFOUTOVbjQYEAvo7+IsPs04h7smctXEDYSe
aN1w0bLWD1UCI7pE0S2pqbQRU1nW/Z6r3Kdu+yP3qpO87ReWFyqLpJEr5gFFL4hFrrIn39+qK
AyRfGkJ4PqbLZaXZ6SwZYc19y08+nmClfhTjHJqVZ7paW/jreXUQ/QvLf9h88gLFy1qrKRs0u
61v0Nk+QlAN06ZgZEqqjctiLFgshzGYCbJw
Michele,
FYI: Sugandha and myself published a Medium blog article which describes =
to build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related =
Knative work.
Link:
=
https://medium.com/@sugandha.agrawal18/build-knative-service-with-tekton-a=
nd-apache-openwhisk-node-js-runtime-f660bbc3a11e
Regards,
Martin
On 2019/05/20 15:00:02, "Michele Sciabarra" wrote:=20=
> Ok great, I see the discussion is starting to bring ideas.>=20
>=20
> Yes my goal is basically to run existing actions in Knative, create =
and invoke. And possibile retain the ability of an action to invoke =
another action.>=20
>=20
> I understand the different way they expose services, so I am =
rethinking the idea of using a "work-alike" path. >=20
>=20
> If it is needed we can add it with an ingress but it may be not =
necessary in the initial implementation.>=20
>=20
> Also I checked a bit ML and discussions and I see this Tekton thing =
that should be the preferred way.>=20
>=20
> Not sure if I understand the relation with the current Build API =
documented in the website. Is Tekton "compatible" or it has a different =
API?>=20
>=20
>=20
> -- >=20
> Michele Sciabarra>=20
> michele@sciabarra.com>=20
>=20
> ----- Original message ----->=20
> From: "Markus Th=C3=B6mmes" >=20
> To: dev@openwhisk.apache.org>=20
> Subject: Re: A plan to (re) implement OpenWhisk on top of Knative>=20
> Date: Monday, May 20, 2019 4:50 PM>=20
>=20
> Good discussion, thanks!>=20
>=20
> Can we try to define what the desired end-goal is here? I'm a bit =
unclear>=20
> what resembling the OpenWhisk API actually buys us.>=20
>=20
> To me, the desired end-state would be to run OpenWhisk actions as-is =
on a>=20
> Knative cluster (similar to OpenFaaS' and Azure's integration). =
There's no>=20
> good way for us to provide the full API without spinning up a control =
plane>=20
> and we can only handle so much via the CLI. So to me, the end-goal =
looks>=20
> like:>=20
>=20
> 1. *wsk action create* actually doing all the pieces necessary to run =
a>=20
> piece of code on Knative.>=20
> 2. *wsk action invoke* doing some HTTP call under the hood to "invoke" =
that>=20
> action. The action should be reachable via a sensible URL. If we =
really>=20
> want to keep the API surface (as I said, I'm dubious here) we can also =
do>=20
> that via ingress level abstractions (like VirtualService).>=20
>=20
> Cheers,>=20
> Markus>=20
>=20
> Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke =
=20
> >:>=20
>=20
> >>=20
> > > On 20. May 2019, at 14:55, Michele Sciabarra =
>=20
> > wrote:>=20
> > >>=20
> > >> Michele,>=20
> > >>=20
> > >> I like the idea to make the ActionLoop based runtimes to be =
runnable on>=20
> > Knative.>=20
> > >>>=20
> > >> My thoughts on this:>=20
> > >> - I second Markus concern to implement the invocation API onto =
Knative>=20
> > instead of just using Knative service syntax.>=20
> > > Can you elaborate this? I do not understand.>=20
> >>=20
> > Knative service syntax: https://=20
> > action)>../>=20
> > OW invocation https://>=20
> > /api/v1/namespaces//actions/>=20
> >>=20
> > (I personally so no worth in inventing a distinct API for OW images, =
but>=20
> > as said I would see that as a valid optional feature)>=20
> >>=20
> > >>=20
> > >> - I would have concerns to make it dependent on Gloo which is =
kind of a>=20
> > minority choice for Knative load balancing>=20
> > > I do not think it will be hard to setup a test also using Istio, I =
do>=20
> > not want to be limited to Gloo.>=20
> >>=20
> > I just wanted to prevent that Gloo gets a =E2=80=9Cofficial=E2=80=9D =
prerequisite for an>=20
> > =E2=80=9Cofficial=E2=80=9D OW on Knative flow.>=20
> > It is of course free to you to use what ever you want to do in your>=20=
> > prototype.>=20
> >>=20
> > > - In my opinion the goal should be to have some uniform behaviour =
for>=20
> > ActionLoop based runtimes>=20
> > >> and other ones like the adapted NodeJS runtimes demonstrated by =
Matt>=20
> > and Priti>=20
> > > As much as I can tell the current implementation is just the =
building>=20
> > and exposing the "/init" and "/run" but I can be wrong.>=20
> > > The build can be of course reused, so it continues the effort. For =
the>=20
> > frontend, from the documentation I think Matt wants to add a proxy, =
while I>=20
> > would like to implemeent the "invocation" straight in the runtime. =
This is>=20
> > open to discussion, but of course it is better to reach an =
agreement.>=20
> >>=20
> > Also in the work of Priti and Matt the invocation goes directly to =
the>=20
> > runtime. The action code is either passed with the call (not yet =
tested by>=20
> > me) or set via environment variable in the docker build.>=20
> >>=20
> > >>=20
> > >> - As Knative Build seems be on a dead end I would propose to =
target>=20
> > Tekton as the build system (which developed as kind of >successor =
out of>=20
> > Knative)>=20
> > >>=20
> > > If Knative build is dead then it would be a bit unfair that they =
change>=20
> > it as the scope of the Knative project!>=20
> > > It looks like the goal is to setup some standards! And I would be =
very>=20
> > disappointed to know that.>=20
> >>=20
> > Tekton evolved out of Knative Build (or more correct out of Knative>=20=
> > Pipelines) but is very similar to the Knative build.>=20
> > Flows can easily be ported from one to the other,>=20
> > If we target Tekton build we would target the platform were the =
Knative>=20
> > build team is focusing on.>=20
> > But again feel free to use whatever platform for your prototype =
work.>=20
> >>=20
> > > At this stage the build is the more interesting thing, and it =
could be>=20
> > even imported in main openwhisk to speed up deployment.>=20
> > > I have already baked it in the ActionLoop runtimes (with =
precompilation).>=20
> > > Also if we use Tekton, where is the Knative standard then? What is =
the>=20
> > point? We can build our own system instead of "Knativizing" it...>=20=
> > >>=20
> > >> Maybe it would be a good solution to tackle two things =
independently.>=20
> > >> 1) Design and implement a common protocol of building, running =
and>=20
> > calling OW runtimes on Knative>=20
> > >> 2) Implement the OW invocation API on top of Knative as an =
additional>=20
> > option for those who have the need to expose it.>=20
> > >>=20
> > > On this, for my personal approach at building things, I want =
something>=20
> > that works and it is complete and useful. A "MVP=E2=80=9D.>=20
> >>=20
> > Cool. Just go on.>=20
> >>=20
> > > So I do not plan to split the effort. Version 0.1 must be a =
minimal>=20
> > working subset of OpenWhisk on Knative.>=20
> > > Because otherwise there will be incomplete useless inusable =
pieces>=20
> > around (see for example kwsk).>=20
> > >>=20
> > > It does not mean that things cannot be modular, nor that everyone =
must>=20
> > but to me "openwhisk-knative" must be a single repo with all the =
pieces to>=20
> > make something where you can download is and deploy in a kubernetes =
cluster>=20
> > and be able to deploy simple actions. When this works, we can =
improve>=20
> > incrementally and split it but keeping it working.>=20
> > >>=20
> > >> I would looking forward to work with you on the first work item.>=20=
> > > Great but I see now more details to discuss before we can start. =
Most>=20
> > notably I need to understand how I can build on top of Mark and =
Priti work>=20
> > and continue their work. ANd I can even probably recover some of the =
code>=20
> > of kwsk as they implemented some openwhisk api, that I want now in =
the>=20
> > runtime.>=20
> > >>=20
> >>=20
> > I do not want to stop you in any way. My hope is that the action =
loop>=20
> > runtimes and the =E2=80=9Cother ones=E2=80=9D do expose the same =
behaviour when being>=20
> > called. So that the users is not surprised when calling different =
actions>=20
> > in different languages.>=20
> > And behaving the same way might also mean to adapt the =E2=80=9Cother =
languages=E2=80=9D>=20
> > to the same behaviour as the action loop based ones.>=20
> > They just should be uniform to be used.>=20
> >>=20
> > When your prototype is accessible it would be a good point of time =
to>=20
> > discuss this.>=20
> >>=20
> > As said I very much like your effort.>=20
> >>=20
> > >>=20
> > >> On 20. May 2019, at 08:55, Michele Sciabarra =
>=20
> > wrote:>=20
> > >>>=20
> > >>>=20
> > >>>> I have an idea for implementing a prototype of OpenWhisk on top =
of>=20
> > Knative.>=20
> > >>>> My basic ideas are: do not use any proxy, forwarding or =
adapter:>=20
> > extend>=20
> > >>>> the runtime to support the REST call and expose them as =
ingress. And>=20
> > use a>=20
> > >>>> wrapper on top of `kubectl` to generate all the needed =
components.>=20
> > >>>=20
> > >>> Does this tie into the work that Matt was doing to the runtimes =
to make>=20
> > >>> them runnable on Knative? Is this lined up with that at all?>=20
> > >> Actually yes. He suggested I can investigate how to migrate =
ActionLoop>=20
> > to port many other languages to Knative.>=20
> > >> Also he recommended I add my idea and this is what I am doing. =
Current>=20
> > code is, if I am not wrong, a Knative build of the nodejs runtime.>=20=
> > >>>=20
> > >> There has been a number of attempts and proposal to move forward>=20=
> > OpenWhisk. My idea that to succeed we need something small but that =
just>=20
> > works. This is my idea to be able to implement in the shorter time =
frame>=20
> > possible an actual subset of OpenWhisk that works and it is truly =
built on>=20
> > top of Knative. So I am putting the thing a bit further than Matt =
work.>=20
> > >>>=20
> > >>>=20
> > >>>> My goal is to have a functional work-alike of OpenWhisk built =
on top>=20
> > of>=20
> > >>>> Knative, using ActionLoop as a foundation. I will extend =
ActionLoop to>=20
> > >>>> support the required REST calls of OpenWhisk.>=20
> > >>>>=20
> > >>>> I also want to create tool, I will call `wskn`. This tool will>=20=
> > initially>=20
> > >>>> just a python script, a wrapper on top of `kubectl` as it will>=20=
> > generate>=20
> > >>>> kubernetes descriptors.>=20
> > >>> Why not build this into "wsk" itself? The Azure Functions CLI as =
an>=20
> > example>=20
> > >>> supports multiple deployment types like this in one CLI.>=20
> > >>>=20
> > >> When it will works, yes, of course. But to start, what I really =
need is>=20
> > a prototype that can generate kubernetes descripttors to feed to =
kubectl,>=20
> > so a simplee, quick and ditry, separate tool (that I will keep =
together>=20
> > the runtime) is all I need for now.>=20
> > >>>=20
> > >>>>>=20
> > >>>> It will support initially just the the action creation and>=20
> > invocation, and>=20
> > >>>> only synchronous (blocking) behaviour, as all the request will =
go>=20
> > straight>=20
> > >>>> to the runtimes. Hopefully also a subset of `package` and>=20
> > `activation`.>=20
> > >>>> Again triggers, rules, asynchronous for later.>=20
> > >>>>>=20
> > >>>> The idea is that you will be able to create actions and web =
actions>=20
> > that>=20
> > >>>> can run existing OpenWhisk actions, at least those with =
blocking>=20
> > behaviour>=20
> > >>>> that run with ActionLoop (Go, Java, Python, PHP, Swift, Rust, =
Ruby,>=20
> > >>>> Crystal...)>=20
> > >>>>>=20
> > >>>> Implementation.>=20
> > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>=20
> > >>>>>=20
> > >>>> This is how I plan to implement it.>=20
> > >>>>>=20
> > >>>> At this stage I want to use just Knative Serving and Knative =
Build,>=20
> > using>=20
> > >>>> Gloo for the ingress part. I also plan to install a local =
Docker>=20
> > registry>=20
> > >>>> Kubernetes registry, so we do not have to use DockerHub for>=20
> > everything. All>=20
> > >>>> of this can be done with existing command line tools in a few =
minutes>=20
> > in>=20
> > >>>> any running Kubernetes deployment.>=20
> > >>>>>=20
> > >>>=20
> > >>> Why specifying Gloo here? Do you need anything specific from =
Gloo>=20
> > itself?>=20
> > >>> If not I'd propose to just keep it on a Knative Serving API =
surface>=20
> > level.>=20
> > >> I want to build it on top of Knative serving, full stop. =
Currently,>=20
> > installing Gloo is pretty easy and is more lightweight than Istio =
so I>=20
> > will use it for my first implementation.>=20
> > >>>=20
> > >>>>>=20
> > >>>> When I create an action, it will use Knative build that will =
work>=20
> > roughly>=20
> > >>>> in this way:>=20
> > >>>>>=20
> > >>>> - create a configmap with the action code>=20
> > >>>> - build the actin using ActionLoop precompilation feature that =
will>=20
> > return>=20
> > >>>> a zip file including all the needed to run the action>=20
> > >>>> - create a new docker image extending the runtime with the new =
zip,>=20
> > using>=20
> > >>>> Kaanico>=20
> > >>>> - push the image in the local registry>=20
> > >>> This feels like a fairly heavyweight process, we should be able =
to>=20
> > come up>=20
> > >>> with a way to circumvent zipping entirely. Maybe the runtime can =
detect>=20
> > >>> that the unzipped content is already there and skip the unzip =
step?>=20
> > >>>=20
> > >> Actually this is my first idea of how to use Knative build. And =
is not>=20
> > complicated: when I create the action, a run a build that includes =
Kanico.>=20
> > I generate a Dockerfile on the fly. The docker file uses the action =
runtime>=20
> > that already know how to compile a script. And then I save an image. =
I>=20
> > already implemented un "autoinit" so just launching the image will =
give a>=20
> > runtime ready to run that execute an action already compiled.>=20
> > >>>=20
> > >>>=20
> > >>> I'm fairly hesitant on the usage of a ConfigMap for storing the =
action>=20
> > >>> code. It's all stored in the in-cluster etcd instance and it has =
a>=20
> > limit of>=20
> > >>> 1M. This is at most a stop-gap solution to provide a PoC I =
think. Any>=20
> > ideas>=20
> > >>> on how to "productize" this?>=20
> > >>>=20
> > >> ConfigMap can be mounted as files, so it is an easy way to feed =
an>=20
> > action to a build. It is just an easy way to feed the action code to =
the>=20
> > Build.>=20
> > >>>=20
> > >> My initial constraint is that I want just to generate Kubernetes>=20=
> > descriptors to feed to kubectl.>=20
> > >> Of course in the long run I can add some "file upload" storage.>=20=
> > >>>=20
> > >> If I could to this file upload when invoking a build it could =
ideal as>=20
> > I do not have to store anything anywhere, just process the code and>=20=
> > generate a single layer to execute actions to be store in the =
registry.>=20
> > >> I will investigate better this area, I understand your concern.>=20=
> > >>>=20
> > >>>>=20
> > >>>> At this point you can run the action. ActionLoop will be =
extended to>=20
> > >>>> support invocations in the format>=20
> > >>>> "/v1/namespaces/namespace/actions/package/action".>=20
> > >>> Why bother reimplementing this exact path? To obtain API =
compatibility>=20
> > with>=20
> > >>> OpenWhisk as it is today?>=20
> > >>>=20
> > >> I want to implement a subset of the OpenWhisk API on top of =
Knative>=20
> > serving.>=20
> > >> Knative serving already does the scaling and routing, so what we =
need>=20
> > are the "endpoints" to invoke actions.>=20
> > >>>=20
> > >> Since I do not want to add additional components, not at the =
first>=20
> > stage. Just knative serve and build, the runtime and a controller =
script,>=20
> > the runtime is the natural place where to "handle" the API =
invocations,>=20
> > since Knative only generates the URL but not anything else. If I>=20=
> > understood well, Matt is adding a proxy. I do not want to add a =
proxy, just>=20
> > add to the runtime the ability to respond to "API like" calls, at =
least>=20
> > those regarding action invocation.>=20
> > >>>=20
> > >>>> It will do all the decoding required to invoke the action with =
the>=20
> > >>>> expected paramenters (straight invocation thrhoug the =
actinloop>=20
> > protocol,>=20
> > >>>> not proxies).>=20
> > >>> Does this mean moving all of the Controller's "smartness" about>=20=
> > incoming>=20
> > >>> and outgoing HTTP requests (see the whole WebActions for =
example)?>=20
> > >>>=20
> > >> At least decoding web actions in the runtime, yes. Knative =
serving>=20
> > already has routing and proxying.>=20
> > >> So a true implementation on top of Knative requires IHMO this>=20
> > sacrifice. Unless there is a way to keep the controller in a =
"Knative">=20
> > compatible way. Open to suggestions here.>=20
> > >>>=20
> > >>> Each action will then be exposed using an ingress with its =
specific>=20
> > >>> invocation path.>=20
> > >>>>=20
> > >>> If the community agrees with this plan, I would create a repo>=20=
> > >>> `incubator-openwhisk-knative` to work on it.>=20
> > >>>>=20
> > >>> Thoughts?>=20
> >>=20
> >>=20
>=20=