You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Priti Desai <pd...@us.ibm.com> on 2019/03/13 18:49:27 UTC
OpenWhisk Apps on Knative
Hi Whiskers,
Matt and I have been working on building OpenWhisk apps on Knative. We
have created build template for NodeJS runtime along with build and
service files for various use cases.
I have created PR under Dev Tools with all our work:
https://github.com/apache/incubator-openwhisk-devtools/pull/202
This PR has documentation and how to for your reference. Will add slide
deck soon.
Here is a list of READMEs you might want to follow in order:
Installing Knative and Istio:
https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/README.md
Deploying Build Template:
https://github.com/apache/incubator-openwhisk-devtools/tree/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript
/README.md
Hello World Sample App:
https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript/tests/helloworld/README.md
We are looking for your feedback and comments, will demo few use cases in
our next community call.
Cheers
Priti
Re: OpenWhisk Apps on Knative
Posted by Lars Andersson <la...@gmail.com>.
Don, I agree with you. The simplicity is what I like about OpenWhisk as
well. As a contrast, I was at a meetup about Knative a couple of months
ago, and at that time basically only the build part was mature enough that
it could be demoed. I remember asking my self what's the point of all this
build stuff with templates and pipelines to create a container? Wasn't one
of the most compelling ideas of serverless to get away from containers and
focus on code instead? To me, it seems as if you are building microservices
rather than functions with Knative? But, that's just based on a short 30
min demo so I might get another understanding of it if I do a deep-dive
into it.
Lars
Den ons 13 mars 2019 kl 22:50 skrev Don Schenck <do...@gmail.com>:
> I work for Red Hat, which is touting Knative as "serverless" pretty hard.
>
> My take: OpenWhisk is so much easier to use. I can write a small function,
> run one command and BOOM I have a function.
>
> I wrote a really involved tutorial and blog series about Knative, but after
> I was finished I learned that we are going with Knative.
>
> I know this isn't helpful, but hopefully you'll find it informational. I
> seem to have a knack for choosing technologies that die (I gave up my
> Windows Phone just last Fall).
>
> -- Don
>
> On Wed, Mar 13, 2019 at 5:33 PM Lars Andersson <
> lars.storfiskarn.andersson@gmail.com> wrote:
>
> > Relevant question indeed! If the controller and invoker were to be
> dropped,
> > what would be the incentive for using OpenWhisk at all, and not go all in
> > on Knative instead?
> >
> > I'm currently working on an RFI from a customer where I see OpenWhisk as
> a
> > good fit, but knowing what's going on with Knative makes me wonder if I
> > should propose Knative instead, even though it might not be fully
> > production ready yet.
> >
> > Lars
> >
> > Den ons 13 mars 2019 kl 21:08 skrev Michele Sciabarra <
> > michele@sciabarra.com
> > >:
> >
> > > So, is the focus of the project shifting on Knative? Dropping the
> current
> > > invoker and controller, keeping the runtimes and run them with Knative?
> > >
> > > --
> > > Michele Sciabarra
> > > michele@sciabarra.com
> > >
> > >
> > >
> > > ----- Original message -----
> > > From: Priti Desai <pd...@us.ibm.com>
> > > To: OpenWhisk Dev <de...@openwhisk.apache.org>
> > > Subject: OpenWhisk Apps on Knative
> > > Date: Wednesday, March 13, 2019 7:49 PM
> > >
> > > Hi Whiskers,
> > >
> > > Matt and I have been working on building OpenWhisk apps on Knative. We
> > > have created build template for NodeJS runtime along with build and
> > > service files for various use cases.
> > >
> > > I have created PR under Dev Tools with all our work:
> > >
> > > https://github.com/apache/incubator-openwhisk-devtools/pull/202
> > >
> > > This PR has documentation and how to for your reference. Will add slide
> > > deck soon.
> > >
> > > Here is a list of READMEs you might want to follow in order:
> > >
> > > Installing Knative and Istio:
> > >
> > >
> >
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/README.md
> > > Deploying Build Template:
> > >
> > >
> >
> https://github.com/apache/incubator-openwhisk-devtools/tree/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript
> > > /README.md
> > > Hello World Sample App:
> > >
> > >
> >
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript/tests/helloworld/README.md
> > >
> > > We are looking for your feedback and comments, will demo few use cases
> in
> > > our next community call.
> > >
> > > Cheers
> > > Priti
> > >
> > >
> > >
> >
>
>
> --
> I'm also on Twitter (@DonSchenck), Facebook (DonSchenck) and Skype
> (schenckdon).
>
Re: OpenWhisk Apps on Knative
Posted by Don Schenck <do...@gmail.com>.
I work for Red Hat, which is touting Knative as "serverless" pretty hard.
My take: OpenWhisk is so much easier to use. I can write a small function,
run one command and BOOM I have a function.
I wrote a really involved tutorial and blog series about Knative, but after
I was finished I learned that we are going with Knative.
I know this isn't helpful, but hopefully you'll find it informational. I
seem to have a knack for choosing technologies that die (I gave up my
Windows Phone just last Fall).
-- Don
On Wed, Mar 13, 2019 at 5:33 PM Lars Andersson <
lars.storfiskarn.andersson@gmail.com> wrote:
> Relevant question indeed! If the controller and invoker were to be dropped,
> what would be the incentive for using OpenWhisk at all, and not go all in
> on Knative instead?
>
> I'm currently working on an RFI from a customer where I see OpenWhisk as a
> good fit, but knowing what's going on with Knative makes me wonder if I
> should propose Knative instead, even though it might not be fully
> production ready yet.
>
> Lars
>
> Den ons 13 mars 2019 kl 21:08 skrev Michele Sciabarra <
> michele@sciabarra.com
> >:
>
> > So, is the focus of the project shifting on Knative? Dropping the current
> > invoker and controller, keeping the runtimes and run them with Knative?
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> >
> >
> > ----- Original message -----
> > From: Priti Desai <pd...@us.ibm.com>
> > To: OpenWhisk Dev <de...@openwhisk.apache.org>
> > Subject: OpenWhisk Apps on Knative
> > Date: Wednesday, March 13, 2019 7:49 PM
> >
> > Hi Whiskers,
> >
> > Matt and I have been working on building OpenWhisk apps on Knative. We
> > have created build template for NodeJS runtime along with build and
> > service files for various use cases.
> >
> > I have created PR under Dev Tools with all our work:
> >
> > https://github.com/apache/incubator-openwhisk-devtools/pull/202
> >
> > This PR has documentation and how to for your reference. Will add slide
> > deck soon.
> >
> > Here is a list of READMEs you might want to follow in order:
> >
> > Installing Knative and Istio:
> >
> >
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/README.md
> > Deploying Build Template:
> >
> >
> https://github.com/apache/incubator-openwhisk-devtools/tree/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript
> > /README.md
> > Hello World Sample App:
> >
> >
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript/tests/helloworld/README.md
> >
> > We are looking for your feedback and comments, will demo few use cases in
> > our next community call.
> >
> > Cheers
> > Priti
> >
> >
> >
>
--
I'm also on Twitter (@DonSchenck), Facebook (DonSchenck) and Skype
(schenckdon).
Re: OpenWhisk Apps on Knative
Posted by Lars Andersson <la...@gmail.com>.
Relevant question indeed! If the controller and invoker were to be dropped,
what would be the incentive for using OpenWhisk at all, and not go all in
on Knative instead?
I'm currently working on an RFI from a customer where I see OpenWhisk as a
good fit, but knowing what's going on with Knative makes me wonder if I
should propose Knative instead, even though it might not be fully
production ready yet.
Lars
Den ons 13 mars 2019 kl 21:08 skrev Michele Sciabarra <michele@sciabarra.com
>:
> So, is the focus of the project shifting on Knative? Dropping the current
> invoker and controller, keeping the runtimes and run them with Knative?
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
>
>
> ----- Original message -----
> From: Priti Desai <pd...@us.ibm.com>
> To: OpenWhisk Dev <de...@openwhisk.apache.org>
> Subject: OpenWhisk Apps on Knative
> Date: Wednesday, March 13, 2019 7:49 PM
>
> Hi Whiskers,
>
> Matt and I have been working on building OpenWhisk apps on Knative. We
> have created build template for NodeJS runtime along with build and
> service files for various use cases.
>
> I have created PR under Dev Tools with all our work:
>
> https://github.com/apache/incubator-openwhisk-devtools/pull/202
>
> This PR has documentation and how to for your reference. Will add slide
> deck soon.
>
> Here is a list of READMEs you might want to follow in order:
>
> Installing Knative and Istio:
>
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/README.md
> Deploying Build Template:
>
> https://github.com/apache/incubator-openwhisk-devtools/tree/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript
> /README.md
> Hello World Sample App:
>
> https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript/tests/helloworld/README.md
>
> We are looking for your feedback and comments, will demo few use cases in
> our next community call.
>
> Cheers
> Priti
>
>
>
Re: OpenWhisk Apps on Knative
Posted by Carlos Santana <cs...@gmail.com>.
Matt Priti I see the PR got merged/closed with no discussion
Here is my initial feedback:
I wasted like 30 minutes looking for the hello.js openwhisk action and how
this was used to build final docker image to be use in knative.
Never found it, after reading every file I think I finally realize that the
openwhisk code is suppose to be a k8s environment variable in the
build.yaml
I never expected this and I think is not a good solution, just editing a
file to get the code in the yaml, encodings, handling package zip actions,
and the limit of env variables when is too large
I think the build template should take an existing openwhisk app directory,
it can be a git repo and directory path (root as default) and look for a
wskdeploy manifest or a serveless framework manifest.
copy that to a knative build workspace and then using the manifest take the
action code and generate one or more docker images, that could then be
refer in a knative service yaml
Looking forward to the openwhisk community meeting that you said you were
going to present more details and demo, before I provide more feedback
-- Carlos
On Fri, Mar 15, 2019 at 8:06 AM James Thomas <jt...@gmail.com> wrote:
> My 2 cents (from a personal perspective - these views are my own and not my
> employers yada yada)...
>
> Despite the marketing hype, (at the moment) knative isn't a serverless
> platform like openwhisk.
>
> It's a Containers-as-a-Service platform (which scales from zero) than a
> Functions-as-a-Service platform. It exposes lots of low-level plumbing to
> the user, (scaling behaviour, k8s YAML, images), which is all hidden in a
> serverless platform.
>
> I think the description on their Github organisation makes more sense...
>
> "Kubernetes-based platform to build, deploy, and manage modern serverless
> workloads".
>
> Building primitives into k8s to make running serverless workloads easier
> make sense. It doesn't necessary mean that developers will use these
> primitives directly.
>
> All the current open-source faas platforms (openwhisk, openfaas, kubeless,
> fission, fn project..) have had to implement the same custom runtime
> primitives on top of lower-level infrastructure services. Those services
> (roughly) map to the knative projects (build, serving, events) being
> proposed.
>
> If you follow Simon Wardley's work, you'll recognise this as a known
> process as these components shifting from custom-built/product-rental to
> commodity/utility on the technology evolution lifecycle.
>
> https://www.youtube.com/watch?v=NnFeIt-uaEc
>
> In theory, Apache OpenWhisk adopting those knative primitives means we can
> focus on higher-order systems and new innovations in the serverless space,
> whilst leaving the lower-level plumbing to the downstream project.
>
> Kelsey Hightower has regularly stated both k8s and knative are tools for
> building platforms, not the platforms developers use.
>
> https://twitter.com/kelseyhightower/status/1104041461836787712
>
> https://twitter.com/kelseyhightower/status/1099710178545434625
>
> There are lots of questions about knative that make things more
> challenging….
>
> -
>
> Will knative stay as lower-level k8s primitives to run serverless
> workloads or move "up the stack" and starts to provide developer tools
> or
> frameworks for serverless apps? The former leaves a gap for openwhisk,
> the
> later less so much (in openwhisk's current incarnation).
> -
>
> What is the governance model for knative? It is not in a foundation at
> the moment and currently (mostly) controlled by Google. Re-basing
> solely on
> knative comes with more of a risk until this is cleared up.
> -
>
> Knative is still extremely immature, it's at like v0.4. The projects
> under the knative organisation, their APIs and goals might change
> substantially over the next 12-24 months.
>
>
>
> On Thu, 14 Mar 2019 at 01:45, Carlos Santana <cs...@gmail.com> wrote:
>
> > I echo Dave’s words
> >
> > To add:
> >
> > OpenWhisk was born before Kubernetes was mainstream
> >
> > OpenWhisk took advantage at that time of Docker CLI and Docker Engine
> > avoiding to re-invent the wheel.
> >
> > OpenWhisk was build and deploy using bash and ant at one point, then
> > gradle, ansible, compose and later Helm
> >
> > Kubernetes has become mainstream and there are things that OpenWhisk do
> > and is concerned today that could be delegated to Kubernetes or
> Kubernetes
> > ecosystem tools and patterns such as Istio, CRD, Controllers, Operators,
> > etc...
> >
> > Like Dave said OpenWhisk can still provide a a better developer
> experience
> > to people that just want to build serverless applications and don’t have
> > any interest on how the low level infrastructure, installation,
> deployment,
> > or scaling layers work.
> >
> > Maybe it means additions to v1, maybe it takes a re-imagination as a v2,
> > maybe it takes building on top of Knative, maybe takes integrating
> trigger
> > providers in the form of native CRDs and Operators, or maybe fusing parts
> > of both projects
> >
> > Like Dave said is up to the community and not a single person or single
> > company
> >
> > - Carlos Santana
> > @csantanapr
> >
> > > On Mar 13, 2019, at 9:17 PM, David P Grove <gr...@us.ibm.com> wrote:
> > >
> > >
> > > "Michele Sciabarra" <mi...@sciabarra.com> wrote on 03/13/2019
> 04:08:15
> > > PM:=
> > >>
> > >> So, is the focus of the project shifting on Knative? Dropping the
> > >> current invoker and controller, keeping the runtimes and run them
> > >> with Knative?
> > >>
> > >
> > > My 2 cents as an individual is that there is quite a bit of value in
> > being
> > > able to program against the OpenWhisk programming model and its
> runtimes
> > in
> > > a more Kubernetes-centric world.
> > >
> > > I think it is still an open question what the best underlying runtime
> > > system for that programming model is (and even if there is a single
> best
> > > runtime system that spans all the possible scenarios in terms of scale,
> > > multi-tenancy, etc.). As a system researcher, one of the best ways I
> know
> > > to explore that question is to be able to run the exact same
> > > program/workload on multiple runtime systems under different scenarios
> > and
> > > measure what happens.
> > >
> > > Our current runtime system probably does need to evolve to better
> exploit
> > > Mesos/Kubernetes (eg Tyson's recent PR). Kubernetes itself is likely
> to
> > > evolve to better support FaaS-style workloads so we will be able to
> have
> > a
> > > thinner OpenWhisk-specific layer. I don't think we should expect every
> > > runtime system design decision we have made to hold constant as
> > technology
> > > evolves around us. But the system-level OpenWhisk runtime could
> > completely
> > > change without any disruption to the user-level programming model and
> > > developer tooling. For example, IBM Cloud Functions switched from a
> > > "classic" ansible-driven VM-based deployment to a Kubernetes-based
> > > deployment of OpenWhisk in the middle of 2018. None of our customers
> > > noticed or cared (from their perspective nothing changed and all their
> > > existing programs still run just fine).
> > >
> > > Finally, the focus of this project is where the community takes it. We
> > can
> > > even go multiple directions simultaneously. That's how open source
> works
> > :)
> > >
> > >
> > > --dave
> >
>
>
> --
> Regards,
> James Thomas
>
--
Carlos Santana
<cs...@gmail.com>
Re: OpenWhisk Apps on Knative
Posted by James Thomas <jt...@gmail.com>.
My 2 cents (from a personal perspective - these views are my own and not my
employers yada yada)...
Despite the marketing hype, (at the moment) knative isn't a serverless
platform like openwhisk.
It's a Containers-as-a-Service platform (which scales from zero) than a
Functions-as-a-Service platform. It exposes lots of low-level plumbing to
the user, (scaling behaviour, k8s YAML, images), which is all hidden in a
serverless platform.
I think the description on their Github organisation makes more sense...
"Kubernetes-based platform to build, deploy, and manage modern serverless
workloads".
Building primitives into k8s to make running serverless workloads easier
make sense. It doesn't necessary mean that developers will use these
primitives directly.
All the current open-source faas platforms (openwhisk, openfaas, kubeless,
fission, fn project..) have had to implement the same custom runtime
primitives on top of lower-level infrastructure services. Those services
(roughly) map to the knative projects (build, serving, events) being
proposed.
If you follow Simon Wardley's work, you'll recognise this as a known
process as these components shifting from custom-built/product-rental to
commodity/utility on the technology evolution lifecycle.
https://www.youtube.com/watch?v=NnFeIt-uaEc
In theory, Apache OpenWhisk adopting those knative primitives means we can
focus on higher-order systems and new innovations in the serverless space,
whilst leaving the lower-level plumbing to the downstream project.
Kelsey Hightower has regularly stated both k8s and knative are tools for
building platforms, not the platforms developers use.
https://twitter.com/kelseyhightower/status/1104041461836787712
https://twitter.com/kelseyhightower/status/1099710178545434625
There are lots of questions about knative that make things more
challenging….
-
Will knative stay as lower-level k8s primitives to run serverless
workloads or move "up the stack" and starts to provide developer tools or
frameworks for serverless apps? The former leaves a gap for openwhisk, the
later less so much (in openwhisk's current incarnation).
-
What is the governance model for knative? It is not in a foundation at
the moment and currently (mostly) controlled by Google. Re-basing solely on
knative comes with more of a risk until this is cleared up.
-
Knative is still extremely immature, it's at like v0.4. The projects
under the knative organisation, their APIs and goals might change
substantially over the next 12-24 months.
On Thu, 14 Mar 2019 at 01:45, Carlos Santana <cs...@gmail.com> wrote:
> I echo Dave’s words
>
> To add:
>
> OpenWhisk was born before Kubernetes was mainstream
>
> OpenWhisk took advantage at that time of Docker CLI and Docker Engine
> avoiding to re-invent the wheel.
>
> OpenWhisk was build and deploy using bash and ant at one point, then
> gradle, ansible, compose and later Helm
>
> Kubernetes has become mainstream and there are things that OpenWhisk do
> and is concerned today that could be delegated to Kubernetes or Kubernetes
> ecosystem tools and patterns such as Istio, CRD, Controllers, Operators,
> etc...
>
> Like Dave said OpenWhisk can still provide a a better developer experience
> to people that just want to build serverless applications and don’t have
> any interest on how the low level infrastructure, installation, deployment,
> or scaling layers work.
>
> Maybe it means additions to v1, maybe it takes a re-imagination as a v2,
> maybe it takes building on top of Knative, maybe takes integrating trigger
> providers in the form of native CRDs and Operators, or maybe fusing parts
> of both projects
>
> Like Dave said is up to the community and not a single person or single
> company
>
> - Carlos Santana
> @csantanapr
>
> > On Mar 13, 2019, at 9:17 PM, David P Grove <gr...@us.ibm.com> wrote:
> >
> >
> > "Michele Sciabarra" <mi...@sciabarra.com> wrote on 03/13/2019 04:08:15
> > PM:=
> >>
> >> So, is the focus of the project shifting on Knative? Dropping the
> >> current invoker and controller, keeping the runtimes and run them
> >> with Knative?
> >>
> >
> > My 2 cents as an individual is that there is quite a bit of value in
> being
> > able to program against the OpenWhisk programming model and its runtimes
> in
> > a more Kubernetes-centric world.
> >
> > I think it is still an open question what the best underlying runtime
> > system for that programming model is (and even if there is a single best
> > runtime system that spans all the possible scenarios in terms of scale,
> > multi-tenancy, etc.). As a system researcher, one of the best ways I know
> > to explore that question is to be able to run the exact same
> > program/workload on multiple runtime systems under different scenarios
> and
> > measure what happens.
> >
> > Our current runtime system probably does need to evolve to better exploit
> > Mesos/Kubernetes (eg Tyson's recent PR). Kubernetes itself is likely to
> > evolve to better support FaaS-style workloads so we will be able to have
> a
> > thinner OpenWhisk-specific layer. I don't think we should expect every
> > runtime system design decision we have made to hold constant as
> technology
> > evolves around us. But the system-level OpenWhisk runtime could
> completely
> > change without any disruption to the user-level programming model and
> > developer tooling. For example, IBM Cloud Functions switched from a
> > "classic" ansible-driven VM-based deployment to a Kubernetes-based
> > deployment of OpenWhisk in the middle of 2018. None of our customers
> > noticed or cared (from their perspective nothing changed and all their
> > existing programs still run just fine).
> >
> > Finally, the focus of this project is where the community takes it. We
> can
> > even go multiple directions simultaneously. That's how open source works
> :)
> >
> >
> > --dave
>
--
Regards,
James Thomas
Re: OpenWhisk Apps on Knative
Posted by Carlos Santana <cs...@gmail.com>.
I echo Dave’s words
To add:
OpenWhisk was born before Kubernetes was mainstream
OpenWhisk took advantage at that time of Docker CLI and Docker Engine avoiding to re-invent the wheel.
OpenWhisk was build and deploy using bash and ant at one point, then gradle, ansible, compose and later Helm
Kubernetes has become mainstream and there are things that OpenWhisk do and is concerned today that could be delegated to Kubernetes or Kubernetes ecosystem tools and patterns such as Istio, CRD, Controllers, Operators, etc...
Like Dave said OpenWhisk can still provide a a better developer experience to people that just want to build serverless applications and don’t have any interest on how the low level infrastructure, installation, deployment, or scaling layers work.
Maybe it means additions to v1, maybe it takes a re-imagination as a v2, maybe it takes building on top of Knative, maybe takes integrating trigger providers in the form of native CRDs and Operators, or maybe fusing parts of both projects
Like Dave said is up to the community and not a single person or single company
- Carlos Santana
@csantanapr
> On Mar 13, 2019, at 9:17 PM, David P Grove <gr...@us.ibm.com> wrote:
>
>
> "Michele Sciabarra" <mi...@sciabarra.com> wrote on 03/13/2019 04:08:15
> PM:=
>>
>> So, is the focus of the project shifting on Knative? Dropping the
>> current invoker and controller, keeping the runtimes and run them
>> with Knative?
>>
>
> My 2 cents as an individual is that there is quite a bit of value in being
> able to program against the OpenWhisk programming model and its runtimes in
> a more Kubernetes-centric world.
>
> I think it is still an open question what the best underlying runtime
> system for that programming model is (and even if there is a single best
> runtime system that spans all the possible scenarios in terms of scale,
> multi-tenancy, etc.). As a system researcher, one of the best ways I know
> to explore that question is to be able to run the exact same
> program/workload on multiple runtime systems under different scenarios and
> measure what happens.
>
> Our current runtime system probably does need to evolve to better exploit
> Mesos/Kubernetes (eg Tyson's recent PR). Kubernetes itself is likely to
> evolve to better support FaaS-style workloads so we will be able to have a
> thinner OpenWhisk-specific layer. I don't think we should expect every
> runtime system design decision we have made to hold constant as technology
> evolves around us. But the system-level OpenWhisk runtime could completely
> change without any disruption to the user-level programming model and
> developer tooling. For example, IBM Cloud Functions switched from a
> "classic" ansible-driven VM-based deployment to a Kubernetes-based
> deployment of OpenWhisk in the middle of 2018. None of our customers
> noticed or cared (from their perspective nothing changed and all their
> existing programs still run just fine).
>
> Finally, the focus of this project is where the community takes it. We can
> even go multiple directions simultaneously. That's how open source works :)
>
>
> --dave
Re: OpenWhisk Apps on Knative
Posted by David P Grove <gr...@us.ibm.com>.
"Michele Sciabarra" <mi...@sciabarra.com> wrote on 03/13/2019 04:08:15
PM:=
>
> So, is the focus of the project shifting on Knative? Dropping the
> current invoker and controller, keeping the runtimes and run them
> with Knative?
>
My 2 cents as an individual is that there is quite a bit of value in being
able to program against the OpenWhisk programming model and its runtimes in
a more Kubernetes-centric world.
I think it is still an open question what the best underlying runtime
system for that programming model is (and even if there is a single best
runtime system that spans all the possible scenarios in terms of scale,
multi-tenancy, etc.). As a system researcher, one of the best ways I know
to explore that question is to be able to run the exact same
program/workload on multiple runtime systems under different scenarios and
measure what happens.
Our current runtime system probably does need to evolve to better exploit
Mesos/Kubernetes (eg Tyson's recent PR). Kubernetes itself is likely to
evolve to better support FaaS-style workloads so we will be able to have a
thinner OpenWhisk-specific layer. I don't think we should expect every
runtime system design decision we have made to hold constant as technology
evolves around us. But the system-level OpenWhisk runtime could completely
change without any disruption to the user-level programming model and
developer tooling. For example, IBM Cloud Functions switched from a
"classic" ansible-driven VM-based deployment to a Kubernetes-based
deployment of OpenWhisk in the middle of 2018. None of our customers
noticed or cared (from their perspective nothing changed and all their
existing programs still run just fine).
Finally, the focus of this project is where the community takes it. We can
even go multiple directions simultaneously. That's how open source works :)
--dave
Re: OpenWhisk Apps on Knative
Posted by Michele Sciabarra <mi...@sciabarra.com>.
So, is the focus of the project shifting on Knative? Dropping the current invoker and controller, keeping the runtimes and run them with Knative?
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Priti Desai <pd...@us.ibm.com>
To: OpenWhisk Dev <de...@openwhisk.apache.org>
Subject: OpenWhisk Apps on Knative
Date: Wednesday, March 13, 2019 7:49 PM
Hi Whiskers,
Matt and I have been working on building OpenWhisk apps on Knative. We
have created build template for NodeJS runtime along with build and
service files for various use cases.
I have created PR under Dev Tools with all our work:
https://github.com/apache/incubator-openwhisk-devtools/pull/202
This PR has documentation and how to for your reference. Will add slide
deck soon.
Here is a list of READMEs you might want to follow in order:
Installing Knative and Istio:
https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/README.md
Deploying Build Template:
https://github.com/apache/incubator-openwhisk-devtools/tree/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript
/README.md
Hello World Sample App:
https://github.com/apache/incubator-openwhisk-devtools/blob/75367c5414739c55ea3331e0422b3275551fbd33/knative-build/runtimes/javascript/tests/helloworld/README.md
We are looking for your feedback and comments, will demo few use cases in
our next community call.
Cheers
Priti