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 <mich...@sciabarra.com> 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://<service(in our case = > >action)>.<namespace>.<host>/ > >OW invocation > >https://<api-host>/api/v1/namespaces/<namespace>/actions/<action> > >(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 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 <mich...@sciabarra.com> 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 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. > >> > >> > >>> 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? > >> > >> 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. > >> > >> 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. > >> > >> 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. > >> I will investigate better this area, I understand your concern. > >> > >>> > >>>> 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? > >> > >> 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. > >> > >> 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. > >> > >>>> 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)? > >> > >> 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. > >> > >>> Each action will then be exposed using an ingress with its specific > >>> invocation path. > >>> > >>> If the community agrees with this plan, I would create a repo > >>> `incubator-openwhisk-knative` to work on it. > >>> > >>> Thoughts? -- Matt Sicker <boa...@gmail.com>
