openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <markusthoem...@apache.org>
Subject Re: A plan to (re) implement OpenWhisk on top of Knative
Date Mon, 20 May 2019 15:04:13 GMT
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 <martin.henke@web.de
>:

> 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 <michele@sciabarra.com>
> 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
> >  michele@sciabarra.com
> >
> > ----- Original message -----
> > From: "Markus Thömmes" <markusthoemmes@apache.org>
> > 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.henke@web.de
> >> :
> >
> >>
> >>> On 20. May 2019, at 14:55, Michele Sciabarra <michele@sciabarra.com>
> >> 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://<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)
> >>
> >>>
> >>>> - 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 <michele@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?
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message