Re: A plan to (re) implement OpenWhisk on top of Knative
Thanks for bringing up Tekton; I was going to suggest taking a look at it since knative was brought up. I'd definitely recommend that over knative-build as it's getting a lot more attention from external contributors from other related projects like Jenkins X, GCP, etc. On Mon, 20 May 2019 at 10:12, Michele Sciabarra wrote: > > >>> - 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:// >action)>../ > >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) > > Understood, thx! Well I need to setup a wildcard domain to work with this > locally I see... > Anyway it is a good idea to do this. > > > > >> - 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. > > >I just wanted to prevent that Gloo gets a “official” prerequisite for an > >“official” OW on Knative flow. > >It is of course free to you to use what ever you want to do in your > >prototype. > > No it will not. My concern is to make something easy to setup. Kubernetes is > already hard enough. > > > > - In my opinion the goal should be to have some uniform behaviour for > > ActionLoop based runtimes > >> 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. > > 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. > But if we use Tekton... hmmm > > > > >> - 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) > > > > If Knative build is dead then it would be a bit unfair that they change it > > as the scope of the Knative project! > > It looks like the goal is to setup some standards! And I would be very > > disappointed to know that. > > >Tekton evolved out of Knative Build (or more correct out of Knative > >Pipelines) but is very similar to the Knative build. > >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. > >But again feel free to use whatever platform for your prototype work. > > From a quick check looks like Tekton is actually the way to go. Sadly it was > not clear reading the documentation. > > > 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... > > > >> 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. > > > > On this, for my personal approach at building things, I want something that > > works and it is complete and useful. A "MVP”. > > 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. > > Because otherwise there will be incomplete useless inusable pieces around > > (see for example kwsk). > > > > 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. > > > >> 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 op
Re: [VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc1)
[x] +1 Approve the release [x] Download links are valid. [x] Checksums and PGP signatures are valid. [x] DISCLAIMER is included. [x] Source code artifacts have correct names matching the current release. [x] LICENSE and NOTICE files are correct for each OpenWhisk repository. [x] All files have license headers as specified by OpenWhisk project policy [1]. [x] No compiled archives bundled in source archive. rcverify.sh (script SHA1: EAFD 9EFB 2FFE 32EF 8AAD 31B3 4478 779B 4A26 F1A5) working in the following directory: /var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA fetching tarball and signatures from https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1 fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc fetching openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 fetching release keys importing keys gpg: key 72AF0CC22C4CF320: "Vincent Hou (Release manager of OpenWhisk) < houshen...@apache.org>" not changed gpg: key 22907064147F886E: "Dave Grove " not changed gpg: key 44667BC927C86D51: "Rodric Rabbah " not changed gpg: Total number processed: 3 gpg: unchanged: 3 unpacking tar ball cloning scancode Cloning into 'incubator-openwhisk-utilities'... remote: Enumerating objects: 57, done. remote: Counting objects: 100% (57/57), done. remote: Compressing objects: 100% (42/42), done. remote: Total 57 (delta 19), reused 37 (delta 12), pack-reused 0 Unpacking objects: 100% (57/57), done. computing sha512 for openwhisk-apigateway-0.10.0-incubating-sources.tar.gz SHA512: openwhisk-apigateway-0.10.0-incubating-sources.tar.gz: 81B334B4 C9AFD450 2917F554 603AAD9F EB7097B7 CB15C4B9 DB602F7C FD7BDA49 088E6B1E ACB8A643 04648DAE F0ABD26B 64F5E6AC 76B52D17 3417B906 81D2F4F0 validating sha512... passed verifying asc... passed (signed-by: Dave Grove ) verifying disclaimer... passed verifing notice... failed (cat '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA/incubator-openwhisk-apigateway-0.10.0-incubating/NOTICE.txt') verifying license... passed verifying sources have proper headers... passed scanning for executable files... passed scanning for non-text files... passed scanning for archives... passed scanning for packages... passed run the following command to remove the scratch space: rm -rf '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA' penguin [runtimes *] tools> cat '/var/folders/q9/s3th42s53d34ftd5wvcypybrgn/T/tmp.NigR35fA/incubator-openwhisk-apigateway-0.10.0-incubating/NOTICE.txt' Apache OpenWhisk API Gateway Copyright 2016-2019 The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). MIT License The following components are provided under the MIT License. See project link for details. (MIT License) fakengx (bsm/fakengx - https://github.com/bsm/fakengx) (MIT License) fakeredis (catwell/fakeredis - https://github.com/catwell/fakeredis) On Mon, May 20, 2019 at 3:03 PM David P Grove wrote: > > > Hi, > > This is a call to vote on releasing version 0.10.0-incubating release > candidate rc1 of the following project module with artifacts built from the > Git repositories and commit IDs listed below. > > * OpenWhisk API Gateway: 1f46de9 > https://github.com/apache/incubator-openwhisk-apigateway/commits/1f46de9 > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc > > > https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 > > This release is comprised of source code distribution only. > > You can use this UNIX script to download the release and verify the > checklist below: > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > > Usage: > curl -s " > > https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD > " -o rcverify.sh > chmod +x rcverify.sh > rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating > rc1 > > NOTE: The NOTICE.txt file will be reported as a failed by rcverify.sh. > This is a known gap in rcverify.sh [2], not an issue with this release > candidate. Please verify the NOTICE.txt file manually. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > Release verification checklist
[VOTE] Release Apache OpenWhisk API Gateway (v0.10.0-incubating, rc1)
Hi, This is a call to vote on releasing version 0.10.0-incubating release candidate rc1 of the following project module with artifacts built from the Git repositories and commit IDs listed below. * OpenWhisk API Gateway: 1f46de9 https://github.com/apache/incubator-openwhisk-apigateway/commits/1f46de9 https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.asc https://dist.apache.org/repos/dist/dev/incubator/openwhisk/apache-openwhisk-0.10.0-incubating-rc1/openwhisk-apigateway-0.10.0-incubating-sources.tar.gz.sha512 This release is comprised of source code distribution only. You can use this UNIX script to download the release and verify the checklist below: https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD Usage: curl -s " https://gitbox.apache.org/repos/asf?p=incubator-openwhisk-release.git;a=blob_plain;f=tools/rcverify.sh;hb=HEAD " -o rcverify.sh chmod +x rcverify.sh rcverify.sh openwhisk-apigateway 'OpenWhisk API Gateway' 0.10.0-incubating rc1 NOTE: The NOTICE.txt file will be reported as a failed by rcverify.sh. This is a known gap in rcverify.sh [2], not an issue with this release candidate. Please verify the NOTICE.txt file manually. Please vote to approve this release: [ ] +1 Approve the release [ ] 0 Don't care [ ] -1 Don't release, because ... Release verification checklist for reference: [ ] Download links are valid. [ ] Checksums and PGP signatures are valid. [ ] DISCLAIMER is included. [ ] Source code artifacts have correct names matching the current release. [ ] LICENSE and NOTICE files are correct for each OpenWhisk repository. [ ] All files have license headers as specified by OpenWhisk project policy [1]. [ ] No compiled archives bundled in source archive. This majority vote is open for at least 72 hours. [1] https://github.com/apache/incubator-openwhisk-release/blob/master/docs/license_compliance.md [2] https://github.com/apache/incubator-openwhisk-release/issues/281
[DISCUSS] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
Further to the previous email thread, does anyone have anything they want to add about a potential release for the Apache OpenWhisk Runtime Node.js? The main feature I want to get out in this release is Node.js v12 support. I'll wait a few days before re-opening the VOTE thread. https://github.com/apache/incubator-openwhisk-runtime-nodejs/commit/386b13d5642e7e8d9dee00913fc97d529c9637ef -- Regards, James Thomas
Re: [VOTE] Release Apache OpenWhisk Runtime Node.js (v0.14.0, rc1)
Thanks for the clarification Betrand. I'd actually thought I'd opened a DISCUSS already (but obviously not...). I did want to do this, will send it out now. On Sat, 18 May 2019 at 09:13, Bertrand Delacretaz wrote: > Hi, > > On Fri, May 17, 2019 at 6:42 PM Carlos Santana > wrote: > > ...I didn’t see a [DISCUSS] thread before this [VOTE] thread.. > > Discuss threads are not a requirement, but if you actually have > something to discuss it's fair to ask for that of course. > > Or, this pPMC could make them required *for this project* but I don't > think that has happened. And if it has we need an URL that documents > it. > > > ...This are the type of things that the board will be looking for > > graduation criteria... > > The Incubator PMC (it's not the Board who looks at these details) is > not going to ask for those, > http://www.apache.org/legal/release-policy.html#release-approval lists > what's required for releases. > > -Bertrand > -- Regards, James Thomas
Re: A plan to (re) implement OpenWhisk on top of Knative
>>> - 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://action)>../ >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) Understood, thx! Well I need to setup a wildcard domain to work with this locally I see... Anyway it is a good idea to do this. > >> - 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. >I just wanted to prevent that Gloo gets a “official” prerequisite for an >“official” OW on Knative flow. >It is of course free to you to use what ever you want to do in your prototype. No it will not. My concern is to make something easy to setup. Kubernetes is already hard enough. > - In my opinion the goal should be to have some uniform behaviour for > ActionLoop based runtimes >> 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. > 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. But if we use Tekton... hmmm > >> - 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) > > If Knative build is dead then it would be a bit unfair that they change it as > the scope of the Knative project! > It looks like the goal is to setup some standards! And I would be very > disappointed to know that. >Tekton evolved out of Knative Build (or more correct out of Knative Pipelines) >but is very similar to the Knative build. >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. >But again feel free to use whatever platform for your prototype work. >From a quick check looks like Tekton is actually the way to go. Sadly it was >not clear reading the documentation. > 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... > >> 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. > > On this, for my personal approach at building things, I want something that > works and it is complete and useful. A "MVP”. 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. > Because otherwise there will be incomplete useless inusable pieces around > (see for example kwsk). > > 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. > >> 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. > >I do not want to stop you in any way. My hope is that the action loop runtimes >and the “other ones” 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 “other languages” to >the same behaviour as the action loop based >ones. >They just should be uniform to be used. >When your prototype is acces
Re: A plan to (re) implement OpenWhisk on top of Knative
For background: Tekton has emerged out of the former Knative Build-Pipelines project. The Build API connection will be dropped in Serving v1beta1. Tekton is the way to go if any. Cheers, Markus Am Mo., 20. Mai 2019 um 17:03 Uhr schrieb Martin Henke : > Tekton is different but very very similar. You get a lot of DejaVus. No > big learning Curve. > > Martin > > > > On 20. May 2019, at 17:00, Michele Sciabarra > wrote: > > > > Ok great, I see the discussion is starting to bring ideas. > > > > 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. > > > > I understand the different way they expose services, so I am rethinking > the idea of using a "work-alike" path. > > > > If it is needed we can add it with an ingress but it may be not > necessary in the initial implementation. > > > > Also I checked a bit ML and discussions and I see this Tekton thing that > should be the preferred way. > > > > 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? > > > > > > -- > > Michele Sciabarra > > mich...@sciabarra.com > > > > - Original message - > > From: "Markus Thömmes" > > To: dev@openwhisk.apache.org > > Subject: Re: A plan to (re) implement OpenWhisk on top of Knative > > Date: Monday, May 20, 2019 4:50 PM > > > > Good discussion, thanks! > > > > 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). > > > > Cheers, > > Markus > > > > Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke < > martin.he...@web.de > >> : > > > >> > >>> On 20. May 2019, at 14:55, Michele Sciabarra > >> wrote: > >>> > Michele, > >>> > I like the idea to make the ActionLoop based runtimes to be runnable > on > >> Knative. > > 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:// >> action)>../ > >> 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) > >> > >>> > - 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. > >> > >> I just wanted to prevent that Gloo gets a “official” prerequisite for an > >> “official” 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 > 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. > >>> 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. > >> > >>> > - 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) > >>> > >>> If Knative build is dead then it would be a bit unfair that they change > >> it as the scope of the Knative project! > >>> It looks like the goal is to setup some standards! And I would be very > >> disappointed to know that. > >> > >> Tekton evolved out of Knative Build (or more correct out of Knative > >> Pipelines) but is v
Re: A plan to (re) implement OpenWhisk on top of Knative
Tekton is different but very very similar. You get a lot of DejaVus. No big learning Curve. Martin > On 20. May 2019, at 17:00, Michele Sciabarra wrote: > > Ok great, I see the discussion is starting to bring ideas. > > 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. > > I understand the different way they expose services, so I am rethinking the > idea of using a "work-alike" path. > > If it is needed we can add it with an ingress but it may be not necessary in > the initial implementation. > > Also I checked a bit ML and discussions and I see this Tekton thing that > should be the preferred way. > > 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? > > > -- > Michele Sciabarra > mich...@sciabarra.com > > - Original message - > From: "Markus Thömmes" > To: dev@openwhisk.apache.org > Subject: Re: A plan to (re) implement OpenWhisk on top of Knative > Date: Monday, May 20, 2019 4:50 PM > > Good discussion, thanks! > > 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). > > Cheers, > Markus > > Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke > : > >> >>> On 20. May 2019, at 14:55, Michele Sciabarra >> wrote: >>> Michele, >>> I like the idea to make the ActionLoop based runtimes to be runnable on >> Knative. 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://> action)>../ >> 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) >> >>> - 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. >> >> I just wanted to prevent that Gloo gets a “official” prerequisite for an >> “official” 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 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. >>> 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. >> >>> - 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) >>> >>> If Knative build is dead then it would be a bit unfair that they change >> it as the scope of the Knative project! >>> It looks like the goal is to setup some standards! And I would be very >> disappointed to know that. >> >> Tekton evolved out of Knative Build (or more correct out of Knative >> Pipelines) but is very similar to the Knative build. >> 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. >> 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). >>>
Re: A plan to (re) implement OpenWhisk on top of Knative
Ok great, I see the discussion is starting to bring ideas. 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. I understand the different way they expose services, so I am rethinking the idea of using a "work-alike" path. If it is needed we can add it with an ingress but it may be not necessary in the initial implementation. Also I checked a bit ML and discussions and I see this Tekton thing that should be the preferred way. 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? -- Michele Sciabarra mich...@sciabarra.com - Original message - From: "Markus Thömmes" To: dev@openwhisk.apache.org Subject: Re: A plan to (re) implement OpenWhisk on top of Knative Date: Monday, May 20, 2019 4:50 PM Good discussion, thanks! 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). Cheers, Markus Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke : > > > On 20. May 2019, at 14:55, Michele Sciabarra > wrote: > > > >> Michele, > > > >> I like the idea to make the ActionLoop based runtimes to be runnable on > Knative. > >> > >> 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:// action)>../ > 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) > > > > >> - 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. > > I just wanted to prevent that Gloo gets a “official” prerequisite for an > “official” 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 > >> 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. > > 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. > > > > >> - 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) > > > > If Knative build is dead then it would be a bit unfair that they change > it as the scope of the Knative project! > > It looks like the goal is to setup some standards! And I would be very > disappointed to know that. > > Tekton evolved out of Knative Build (or more correct out of Knative > Pipelines) but is very similar to the Knative build. > 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. > 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... > > > >> 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 > >>
Re: A plan to (re) implement OpenWhisk on top of Knative
Good discussion, thanks! 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). Cheers, Markus Am Mo., 20. Mai 2019 um 15:33 Uhr schrieb Martin Henke : > > > On 20. May 2019, at 14:55, Michele Sciabarra > wrote: > > > >> Michele, > > > >> I like the idea to make the ActionLoop based runtimes to be runnable on > Knative. > >> > >> 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:// action)>../ > 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) > > > > >> - 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. > > I just wanted to prevent that Gloo gets a “official” prerequisite for an > “official” 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 > >> 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. > > 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. > > > > >> - 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) > > > > If Knative build is dead then it would be a bit unfair that they change > it as the scope of the Knative project! > > It looks like the goal is to setup some standards! And I would be very > disappointed to know that. > > Tekton evolved out of Knative Build (or more correct out of Knative > Pipelines) but is very similar to the Knative build. > 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. > 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... > > > >> 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. > > > > On this, for my personal approach at building things, I want something > that works and it is complete and useful. A "MVP”. > > 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. > > Because otherwise there will be incomplete useless inusable pieces > around (see for example kwsk). > > > > 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. > > > >> I would looking forward to work with you on the first
Re: A plan to (re) implement OpenWhisk on top of Knative
> On 20. May 2019, at 14:55, Michele Sciabarra wrote: > >> Michele, > >> I like the idea to make the ActionLoop based runtimes to be runnable on >> Knative. >> >> 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) > >> - 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. I just wanted to prevent that Gloo gets a “official” prerequisite for an “official” 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 >> 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. > 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. > >> - 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) > > If Knative build is dead then it would be a bit unfair that they change it as > the scope of the Knative project! > It looks like the goal is to setup some standards! And I would be very > disappointed to know that. Tekton evolved out of Knative Build (or more correct out of Knative Pipelines) but is very similar to the Knative build. 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. 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... > >> 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. > > On this, for my personal approach at building things, I want something that > works and it is complete and useful. A "MVP”. 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. > Because otherwise there will be incomplete useless inusable pieces around > (see for example kwsk). > > 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. > >> 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. > I do not want to stop you in any way. My hope is that the action loop runtimes and the “other ones” 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 “other languages” to the same behaviour as the action loop based ones. They just should be uniform to be used. When your prototype is accessible it would be a good point of time to discuss this. As said I very much like your effort. > >> On 20. May 2019, at 08:55, Michele Sciabarra wrote: >> >> I have an idea for implementing a prototype of OpenWhisk o
Re: A plan to (re) implement OpenWhisk on top of Knative
Yes but... Knative is supposed to define some "standards" for bulding, serving and eventing. Also I do not look after any "decent" UI, building in OpenWhisk is (and must be) a hidden detail. You send the sources and run the image. ActionLoop images are already able to precompile. The difference would be that at init time I "build" basically creating an image from a runtime with an additional layer with the code of the action (compiled in case of go swift and rust) that can be automatically executed, with no delay of /init (images will "autoinit" with that code). I already implemented that in ActionLoop. This thing as I described is small enough that can be implemented in a reasonable amount of time, and it is fully "Knative" compliant. If I do not do it an "openwhisk on top of knative" I am wasting my time as the current OpenWhisk is already way better. I want just to create a "MVP" and from there understand if merging, replace or reuse the pieces. Unfortunately only when you have something that exists and works you are able to understand what to do next properly. -- Michele Sciabarra mich...@sciabarra.com - Original message - From: Martin Henke To: dev@openwhisk.apache.org Subject: Re: A plan to (re) implement OpenWhisk on top of Knative Date: Monday, May 20, 2019 2:47 PM Bertrand, I am not directly involved in Knative Build or Tekton so I might be wrong on my dead end sentence. For what I got ,I think It was realised that a build pipeline on Kube and the task to build docker containers from a given source is a general problem to solve and in most ways independent from Knative. The good side on this that step is that Jenkins X (the next version of Jenkins) is embracing Tekton already as a runtime. So some would probably get a decent Build UI. Regards, Martin > On 20. May 2019, at 14:17, Bertrand Delacretaz wrote: > > On Mon, May 20, 2019 at 2:07 PM Martin Henke wrote: >> ...As Knative Build seems be on a dead end... > > Wow, already? That stuff seems to be competing with JavaScript > frameworks in terms of short lifetimes these days ;-) > > -Bertrand
Re: Help answering last few Project Maturity Model Qs for graduation readiness
I strongly echo Chetan's statements and also put my own words below. [CS50] *All "important" discussions happen asynchronously in written form on ..." 1. All significant project communication for the project has and is happening asynchronously and in writing: on GitHub with attention solicited from the dev list for issues and PRs. And our community call minutes are documented on the wiki, as are longer term design discussions. > [IN10] *The project is independent from any corporate or organizational influence.* 2. It's quite fair and accurate to say the project has moved beyond the influence of any one organization and specifically "IBM which helped charter the project". This is evident from the Git contributions and activity dating back more than 12 months now. > [IN20] *Contributors act as themselves as opposed to representatives of a corporation or organization.* > [CO60] The community operates based on consensus of its members (see CS10) who have decision power. Dictators, benevolent or not, are not welcome in Apache projects. 3. The project independence is evident from consensus building among members of the project, on this same dev list, who put forth proposal and seek comments. -r
Re: A plan to (re) implement OpenWhisk on top of Knative
>Michele, >I like the idea to make the ActionLoop based runtimes to be runnable on >Knative. > >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. >- 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. - In my opinion the goal should be to have some uniform behaviour for ActionLoop based runtimes >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. 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. >- 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) If Knative build is dead then it would be a bit unfair that they change it as the scope of the Knative project! It looks like the goal is to setup some standards! And I would be very disappointed to know that. 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... >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. On this, for my personal approach at building things, I want something that works and it is complete and useful. A "MVP". So I do not plan to split the effort. Version 0.1 must be a minimal working subset of OpenWhisk on Knative. Because otherwise there will be incomplete useless inusable pieces around (see for example kwsk). 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. >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. > On 20. May 2019, at 08:55, Michele Sciabarra wrote: > > >>> 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. > >> 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. > > 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. > > >>> 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. >> >>> 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. > > 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
Re: A plan to (re) implement OpenWhisk on top of Knative
Bertrand, I am not directly involved in Knative Build or Tekton so I might be wrong on my dead end sentence. For what I got ,I think It was realised that a build pipeline on Kube and the task to build docker containers from a given source is a general problem to solve and in most ways independent from Knative. The good side on this that step is that Jenkins X (the next version of Jenkins) is embracing Tekton already as a runtime. So some would probably get a decent Build UI. Regards, Martin > On 20. May 2019, at 14:17, Bertrand Delacretaz wrote: > > On Mon, May 20, 2019 at 2:07 PM Martin Henke wrote: >> ...As Knative Build seems be on a dead end... > > Wow, already? That stuff seems to be competing with JavaScript > frameworks in terms of short lifetimes these days ;-) > > -Bertrand
Re: A plan to (re) implement OpenWhisk on top of Knative
On Mon, May 20, 2019 at 2:07 PM Martin Henke wrote: > ...As Knative Build seems be on a dead end... Wow, already? That stuff seems to be competing with JavaScript frameworks in terms of short lifetimes these days ;-) -Bertrand
Re: A plan to (re) implement OpenWhisk on top of Knative
Michele, I like the idea to make the ActionLoop based runtimes to be runnable on Knative. My thoughts on this: - I second Markus concern to implement the invocation API onto Knative instead of just using Knative service syntax. - I would have concerns to make it dependent on Gloo which is kind of a minority choice for Knative load balancing - In my opinion the goal should be to have some uniform behaviour for ActionLoop based runtimes and other ones like the adapted NodeJS runtimes demonstrated by Matt and Priti - 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) 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. I would looking forward to work with you on the first work item. Regards, Martin > On 20. May 2019, at 08:55, Michele Sciabarra wrote: > > >>> 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. > >> 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. > > 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. > > >>> 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. >> >>> 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. > > 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. > >>> >>> 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. >>> >>> 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...) >>> >>> Implementation. >>> == >>> >>> This is how I plan to implement it. >>> >>> 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. >>> > >> 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. > >>> >>> When I create an action, it will use Knative build that will work roughly >>> in this way: >>> >>> - 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? > > Actually
[slack-digest] [2019-05-19] #performance
2019-05-19 16:28:13 UTC - Michele Sciabarra: actually it is already there https://openwhisk-team.slack.com/archives/C9HCXAKJ4/p1558283293004300?thread_ts=1558112407.001400&cid=C9HCXAKJ4 2019-05-19 16:31:25 UTC - Michele Sciabarra: the code but I realized it is not published openwhisk/actionloop-java-v8 https://openwhisk-team.slack.com/archives/C9HCXAKJ4/p1558283485004500?thread_ts=1558112407.001400&cid=C9HCXAKJ4
