From dev-return-3760-archive-asf-public=cust-asf.ponee.io@openwhisk.apache.org Mon May 20 13:33:34 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 72030180627 for ; Mon, 20 May 2019 15:33:34 +0200 (CEST) Received: (qmail 3581 invoked by uid 500); 20 May 2019 13:33:33 -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 3564 invoked by uid 99); 20 May 2019 13:33: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; Mon, 20 May 2019 13:33: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 85A201800C5 for ; Mon, 20 May 2019 13:33:32 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 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_LOW=-0.7, 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-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Bn9rd9PL5cp2 for ; Mon, 20 May 2019 13:33:29 +0000 (UTC) Received: from mout.web.de (mout.web.de [217.72.192.78]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 4514261235 for ; Mon, 20 May 2019 13:33:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1558359203; bh=2lQbe9cvTNNPuotY0Vt/LOhZmjV/KcqyZPzsTeClpVY=; h=X-UI-Sender-Class:From:Subject:Date:References:To:In-Reply-To; b=h+bfisSh8KxtqDRuUxO5EtXxoPP57oiWsGBvIVVvFMUv96vfRXm2jouWodQ3X5zkZ z33BvxoDGauvateDilo1hYESNp5dj2RpewOmUoUF7irie1PBy3ffAItL8saf9ZPlFj K3HfLEuRuhrriyrysWJxgGvIZc9c8wH2r3Qgtv+4= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from dyn-9-152-99-46.boeblingen.de.ibm.com ([195.212.29.187]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LudKu-1gT12h07No-00zoA0 for ; Mon, 20 May 2019 15:33:23 +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.8\)) Subject: Re: A plan to (re) implement OpenWhisk on top of Knative Date: Mon, 20 May 2019 15:33:22 +0200 References: <4C1ADD7D-2569-4EF1-8757-0DF415641A63@web.de> <6f53d813-03fa-47bd-b77a-db6bf5389668@www.fastmail.com> To: dev@openwhisk.apache.org In-Reply-To: <6f53d813-03fa-47bd-b77a-db6bf5389668@www.fastmail.com> Message-Id: <53010C8E-A145-43F3-9E14-57EC9AC3AEB3@web.de> X-Mailer: Apple Mail (2.3445.104.8) X-Provags-ID: V03:K1:0CtLnl/WhlICda7LC56BNIGA5tJ3pN6JFZYo0Zgy19Y3Sj3bSiC stpP7xrB5AlkGII4xB7c6S11aO9NUfX6X0y3EoL0Jp3BHCfYULc4YB8G/nNKzIo33f2lMGi bSMYBLyf8fSWwgIrsjI2GVqvcNnOZHU2/FkhQ7s17QHtbs3WjjUkDH8M7qz+cx473p3/7Xj xKiN7K/z66GJXyLTxWWgg== X-UI-Out-Filterresults: notjunk:1;V03:K0:XYctSoQ5qO4=:1DXjiQ1JUHPMunl+SoZEtj 2lbx7DlIpAjsR++okEqam3MbmM9KRYwNzQBThXJQSJLZyW3Z1GAfNkG7hx0xJnPi8kAFlWS6+ 9iaoqadovIV+t6Qi7t2BtY8cLC/Yg++QQg6w3EnVQTXKWudxY+i2FsoB5hW5WnYzEvxXFVbUx Mu9+PbK2QUUxEXMJQjbTHdgAgWZcVecRl4dr09cY4ehdkzL1Q3glGtB/0wEb1X1sw4GndBeNI lfXJxnmcOYWQzX3cOsfg26ABJss0d6tE92z7goS/0UZ8qGyb90Tp3gDx3rDVDv4/E2XxE2DGw QIZtbYvhKuV0oI+DO0nzvyuVGpR5M0GIeg7mrMk0dHWUyHzVJPpaQe21RQRfMOWWc5odrgkav h9fV+sV2ZhAqg6s7dK1Rk7oRqR3d3fWBd6Y3oCfrFPb4yVEaUh4a7nN3MvyJ4EKqsUqZGRbbY E3rOXuenYNS6n3h5wGNpwDGnX8MrW8AYVvYIBR5h0XlAGD7V9z6J8fY0maeWHU6R0J43+Zt0c kPuPiMz2sLIF2m9eLr7LeKKIg8gYNti6wIUpSOkW1e+b8xCacGukR98aWlBcN9GmVXYPHmuzZ 1/ses6ySlkiNdX23tpVDSgkK7RiiJEeSvB3vNHHcyRjoG9EiSFY4bymTSblrP2CCkEM+Re3wc KM06X8kHTN6bT38ImpKC+GHkxY7WFWQw6WFOlwSNBoXrKOsulnPuHydibj+INnt7SZZ3iOZQr Y9YNBXMabm8B52VsxZOrUt9L9/BuEyMM+B34aq9ljsIRJ7R3RJ1z5XrWj+g6rKtHqF05UTzBw VN/x2upBS+lsodvZTBi69x52w4SJPqc1+M6Wia4JYGu5oi3XhMzWN23hMpPC5/tuNF+GIz+zU PEV5VmqclvEovtpbcEYQNlDX4boahzLNLMcmZ8VWuNxMqstRFpEA4KFLDAIug+apK1oFsFPWo m2Atj/pSjf9mIxNOGEDFEjld+f/AZFb8u+nmMoYzlbNLr+nv9gf5e > On 20. May 2019, at 14:55, Michele Sciabarra = wrote: >=20 >> Michele, >=20 >> I like the idea to make the ActionLoop based runtimes to be runnable = on Knative. >>=20 >> My thoughts on this: >> - I second Markus concern to implement the invocation API onto = Knative instead of just using Knative service syntax. > Can you elaborate this? I do not understand. Knative service syntax: https://../ OW invocation = https:///api/v1/namespaces//actions/ (I personally so no worth in inventing a distinct API for OW images, but = as said I would see that as a valid optional feature) >=20 >> - I would have concerns to make it dependent on Gloo which is kind of = a minority choice for Knative load balancing > I do not think it will be hard to setup a test also using Istio, I do = not want to be limited to Gloo.=20 I just wanted to prevent that Gloo gets a =E2=80=9Cofficial=E2=80=9D = prerequisite for an =E2=80=9Cofficial=E2=80=9D OW on Knative flow. It is of course free to you to use what ever you want to do in your = prototype. > - In my opinion the goal should be to have some uniform behaviour for = ActionLoop based runtimes=20 >> and other ones like the adapted NodeJS runtimes demonstrated by Matt = and Priti > As much as I can tell the current implementation is just the building = 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 = frontend, from the documentation I think Matt wants to add a proxy, = while I would like to implemeent the "invocation" straight in the = runtime. This is open to discussion, but of course it is better to reach = an agreement. Also in the work of Priti and Matt the invocation goes directly to the = runtime. The action code is either passed with the call (not yet tested = by me) or set via environment variable in the docker build. >=20 >> - As Knative Build seems be on a dead end I would propose to target = Tekton as the build system (which developed as kind of >successor out of = Knative) >=20 > If Knative build is dead then it would be a bit unfair that they = change it as the scope of the Knative project!=20 > It looks like the goal is to setup some standards! And I would be = very disappointed to know that.=20 Tekton evolved out of Knative Build (or more correct out of Knative = Pipelines) but is very similar to the Knative build.=20 Flows can easily be ported from one to the other, If we target Tekton build we would target the platform were the Knative = build team is focusing on.=20 But again feel free to use whatever platform for your prototype work. > At this stage the build is the more interesting thing, and it could be = even imported in main openwhisk to speed up deployment. > I have already baked it in the ActionLoop runtimes (with = precompilation). > Also if we use Tekton, where is the Knative standard then? What is the = point? We can build our own system instead of "Knativizing" it... >=20 >> Maybe it would be a good solution to tackle two things independently. >> 1) Design and implement a common protocol of building, running and = calling OW runtimes on Knative >> 2) Implement the OW invocation API on top of Knative as an additional = option for those who have the need to expose it. >=20 > On this, for my personal approach at building things, I want something = that works and it is complete and useful. A "MVP=E2=80=9D. Cool. Just go on. > So I do not plan to split the effort. Version 0.1 must be a minimal = working subset of OpenWhisk on Knative.=20 > Because otherwise there will be incomplete useless inusable pieces = around (see for example kwsk). >=20 > It does not mean that things cannot be modular, nor that everyone must = but to me "openwhisk-knative" must be a single repo with all the pieces = to make something where you can download is and deploy in a kubernetes = cluster and be able to deploy simple actions. When this works, we can = improve incrementally and split it but keeping it working. >=20 >> I would looking forward to work with you on the first work item. > Great but I see now more details to discuss before we can start. Most = notably I need to understand how I can build on top of Mark and Priti = work and continue their work. ANd I can even probably recover some of = the code of kwsk as they implemented some openwhisk api, that I want now = in the runtime. >=20 I do not want to stop you in any way. My hope is that the action loop = runtimes and the =E2=80=9Cother ones=E2=80=9D do expose the same = behaviour when being called. So that the users is not surprised when = calling different actions in different languages. And behaving the same way might also mean to adapt the =E2=80=9Cother = languages=E2=80=9D to the same behaviour as the action loop based ones. They just should be uniform to be used.=20 When your prototype is accessible it would be a good point of time to = discuss this. As said I very much like your effort. >=20 >> On 20. May 2019, at 08:55, Michele Sciabarra = wrote: >>=20 >>=20 >>>> I have an idea for implementing a prototype of OpenWhisk on top of = Knative. >>>> My basic ideas are: do not use any proxy, forwarding or adapter: = extend >>>> the runtime to support the REST call and expose them as ingress. = And use a >>>> wrapper on top of `kubectl` to generate all the needed components. >>=20 >>> Does this tie into the work that Matt was doing to the runtimes to = make >>> them runnable on Knative? Is this lined up with that at all? >> Actually yes. He suggested I can investigate how to migrate = ActionLoop to port many other languages to Knative. >> Also he recommended I add my idea and this is what I am doing. = Current code is, if I am not wrong, a Knative build of the nodejs = runtime. >>=20 >> There has been a number of attempts and proposal to move forward = OpenWhisk. My idea that to succeed we need something small but that just = works. This is my idea to be able to implement in the shorter time frame = possible an actual subset of OpenWhisk that works and it is truly built = on top of Knative. So I am putting the thing a bit further than Matt = work. >>=20 >>=20 >>>> My goal is to have a functional work-alike of OpenWhisk built on = top of >>>> Knative, using ActionLoop as a foundation. I will extend ActionLoop = to >>>> support the required REST calls of OpenWhisk. >>>=20 >>>> I also want to create tool, I will call `wskn`. This tool will = initially >>>> just a python script, a wrapper on top of `kubectl` as it will = generate >>>> kubernetes descriptors. >>> Why not build this into "wsk" itself? The Azure Functions CLI as an = example >>> supports multiple deployment types like this in one CLI. >>=20 >> When it will works, yes, of course. But to start, what I really need = is a prototype that can generate kubernetes descripttors to feed to = kubectl, so a simplee, quick and ditry, separate tool (that I will keep = together the runtime) is all I need for now. >>=20 >>>>=20 >>>> It will support initially just the the action creation and = invocation, and >>>> only synchronous (blocking) behaviour, as all the request will go = straight >>>> to the runtimes. Hopefully also a subset of `package` and = `activation`. >>>> Again triggers, rules, asynchronous for later. >>>>=20 >>>> The idea is that you will be able to create actions and web actions = that >>>> can run existing OpenWhisk actions, at least those with blocking = behaviour >>>> that run with ActionLoop (Go, Java, Python, PHP, Swift, Rust, Ruby, >>>> Crystal...) >>>>=20 >>>> Implementation. >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> This is how I plan to implement it. >>>>=20 >>>> At this stage I want to use just Knative Serving and Knative Build, = using >>>> Gloo for the ingress part. I also plan to install a local Docker = registry >>>> Kubernetes registry, so we do not have to use DockerHub for = everything. All >>>> of this can be done with existing command line tools in a few = minutes in >>>> any running Kubernetes deployment. >>>>=20 >>=20 >>> Why specifying Gloo here? Do you need anything specific from Gloo = itself? >>> If not I'd propose to just keep it on a Knative Serving API surface = level. >> I want to build it on top of Knative serving, full stop. Currently, = installing Gloo is pretty easy and is more lightweight than Istio so I = will use it for my first implementation.=20 >>=20 >>>>=20 >>>> When I create an action, it will use Knative build that will work = roughly >>>> in this way: >>>>=20 >>>> - create a configmap with the action code >>>> - build the actin using ActionLoop precompilation feature that will = return >>>> a zip file including all the needed to run the action >>>> - create a new docker image extending the runtime with the new zip, = using >>>> Kaanico >>>> - push the image in the local registry >>> This feels like a fairly heavyweight process, we should be able to = come up >>> with a way to circumvent zipping entirely. Maybe the runtime can = detect >>> that the unzipped content is already there and skip the unzip step? >>=20 >> Actually this is my first idea of how to use Knative build. And is = not complicated: when I create the action, a run a build that includes = Kanico. I generate a Dockerfile on the fly. The docker file uses the = action runtime that already know how to compile a script. And then I = save an image. I already implemented un "autoinit" so just launching the = image will give a runtime ready to run that execute an action already = compiled. >>=20 >>=20 >>> I'm fairly hesitant on the usage of a ConfigMap for storing the = action >>> code. It's all stored in the in-cluster etcd instance and it has a = limit of >>> 1M. This is at most a stop-gap solution to provide a PoC I think. = Any ideas >>> on how to "productize" this? >>=20 >> ConfigMap can be mounted as files, so it is an easy way to feed an = action to a build. It is just an easy way to feed the action code to the = Build. >>=20 >> My initial constraint is that I want just to generate Kubernetes = descriptors to feed to kubectl. >> 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 I do not have to store anything anywhere, just process the code and = 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 >>>> At this point you can run the action. ActionLoop will be extended = to >>>> support invocations in the format >>>> "/v1/namespaces/namespace/actions/package/action". >>> Why bother reimplementing this exact path? To obtain API = compatibility with >>> OpenWhisk as it is today? >>=20 >> I want to implement a subset of the OpenWhisk API on top of Knative = serving. >> Knative serving already does the scaling and routing, so what we need = are the "endpoints" to invoke actions. >>=20 >> Since I do not want to add additional components, not at the first = stage. Just knative serve and build, the runtime and a controller = script, the runtime is the natural place where to "handle" the API = invocations, since Knative only generates the URL but not anything else. = If I understood well, Matt is adding a proxy. I do not want to add a = proxy, just add to the runtime the ability to respond to "API like" = calls, at least those regarding action invocation. >>=20 >>>> It will do all the decoding required to invoke the action with the >>>> expected paramenters (straight invocation thrhoug the actinloop = protocol, >>>> not proxies). >>> Does this mean moving all of the Controller's "smartness" about = incoming >>> and outgoing HTTP requests (see the whole WebActions for example)? >>=20 >> At least decoding web actions in the runtime, yes. Knative serving = already has routing and proxying. >> So a true implementation on top of Knative requires IHMO this = sacrifice. Unless there is a way to keep the controller in a "Knative" = compatible way. Open to suggestions here. >>=20 >>> Each action will then be exposed using an ingress with its specific >>> invocation path. >>>=20 >>> If the community agrees with this plan, I would create a repo >>> `incubator-openwhisk-knative` to work on it. >>>=20 >>> Thoughts?