Fine-grained permission

[Dominic Kim]

Recently I discussed this:
https://github.com/apache/incubator-openwhisk/pull/4058 with my colleagues.
That PR is to add a feature to protect actions from deletion by mistake.
That is a good suggestion and I think we can also include more generalized
way to handle the issue.

For example, what we can expect about permission are as follows.

1. Action protection.
2. Hide codes from the shared package.

I am a bit faint but IIRC, Rodric suggested linux-like permission
management.

Regarding number 1, we can achieve it with the permission, "Read / not
Write / Execute".
And with regared to number 2, we can also achieve it with the permission,
"not Read / not Write (this is the default of shared package action) /
Execute".

If we apply linux-like permission to these cases, we can have two different
permission flags, one for owners, the other for users of shared packages.
Then actions can have permission information such as "71" or "51".
So "71" would mean the owner of an action can do "read/write/execute" it
but the one who uses the shared action would be able to do "not read/not
write/execute".
"51" would mean the owner can do "read/not write/execute".

There might be more cases, but I believe we can deal with them in the same
way.
Any feedback or idea on this would be appreciated.

Thanks
Best regards,
Dominic

rationale for wskdeploy Docker image

[David P Grove]

Do we really need to be publishing a wskdeploy image to dockerhub?

I'm not understanding why this image needs to be public (it appears to
perhaps be an image for building wskdeploy?).

thanks,

--dave

Re: Re: Re: A plan to (re) implement OpenWhisk on top of Knative

[Matt Rutkowski]

FYI, Priti and I spoke earlier this week about exploring the addition of 
new "build" command for wskdeploy that could utilize Tekton.

Kind regards,
Matt




From:   "Michele Sciabarra" 
To: dev@openwhisk.apache.org
Date:   07/03/2019 12:06 PM
Subject:[EXTERNAL] Re:  Re: A plan to (re) implement OpenWhisk on 
top of Knative



Well it  is actually a bit more complex than this.

If we use Tekton for building, it is Tekton the standard, so as long as we 
define a standard for input and output, we delegate to a tekton build the 
preparation  of an image ready for being served by Knative  Serving,

However the action loop based runtimes rely on a "compilation" script 
already written in python that performs the steps, so all I need to do is 
to adapt the compilation to the Tekton standard. This is something I 
already did, at lest for Go, modifying the actionloop codee and I am now 
trying to complete the pipeline. 

The way I did for Go was not getting rid of the "init" step but providing 
an "autoinit" step that happens at runtime start, executing a binary 
executable already embedded in the image and produced by the compilation 
done by the runtime itself.

All of this is more complex to say  than to do so I hope I can show 
something soon... hopefully pretty interesting.

---
Michele Sciabarra
 mich...@sciabarra.com

PS the book "learning Apache OpenWhisk" is now on printing!

- Original message -
From: Matt Rutkowski 
To: dev@openwhisk.apache.org
Subject: Re:  Re: A plan to (re) implement OpenWhisk on top of Knative
Date: Wednesday, July 03, 2019 4:43 PM

Hi Martin, 

It is my belief that Michele, now freshly returned from book editing 
(congrats), was going to implement the same interface for pre/post 
processing requests that we implemented for NodeJS.  This would allow us a 

path to support this across all language runtimes as well as formalize our 

runtime contract that aligns with a Knative Service approach and then also 

allows us to better explore some of the use cases being discussed on 
another thread from Rodric.  I believe that we should look at smaller 
steps towards that alignment like removing the need for the "init" 
entrypoint and allowing access to parameters either by env. vars. or 
function arguments allowing both compat. with 12-factor app approach, as 
well as attempting to encourage a functional programming model where you 
should ideally be unaware of any system environment.

Kind regards,
Matt 




From:   Martin Henke 
To: dev@openwhisk.apache.org
Date:   07/03/2019 09:29 AM
Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top 
of Knative



Michele,

FYI: Sugandha and myself published a Medium blog article which describes 
to build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related Knative 
work.

Link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0&s=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454&e=
 



Regards,
Martin


On 2019/05/20 15:00:02, "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

Re: Re: A plan to (re) implement OpenWhisk on top of Knative

[Michele Sciabarra]

Well it  is actually a bit more complex than this.

If we use Tekton for building, it is Tekton the standard, so as long as we 
define a standard for input and output, we delegate to a tekton build the 
preparation  of an image ready for being served by Knative  Serving,

However the action loop based runtimes rely on a "compilation" script already 
written in python that performs the steps, so all I need to do is to adapt the 
compilation to the Tekton standard. This is something I already did, at lest 
for Go, modifying the actionloop codee and I am now trying to complete the 
pipeline. 

The way I did for Go was not getting rid of the "init" step but providing an 
"autoinit" step that happens at runtime start, executing a binary executable 
already embedded in the image and produced by the compilation done by the 
runtime itself.

All of this is more complex to say  than to do so I hope I can show something 
soon... hopefully pretty interesting.

---
Michele Sciabarra
 mich...@sciabarra.com

PS the book "learning Apache OpenWhisk" is now on printing!

- Original message -
From: Matt Rutkowski 
To: dev@openwhisk.apache.org
Subject: Re:  Re: A plan to (re) implement OpenWhisk on top of Knative
Date: Wednesday, July 03, 2019 4:43 PM

Hi Martin, 

It is my belief that Michele, now freshly returned from book editing 
(congrats), was going to implement the same interface for pre/post 
processing requests that we implemented for NodeJS.  This would allow us a 
path to support this across all language runtimes as well as formalize our 
runtime contract that aligns with a Knative Service approach and then also 
allows us to better explore some of the use cases being discussed on 
another thread from Rodric.  I believe that we should look at smaller 
steps towards that alignment like removing the need for the "init" 
entrypoint and allowing access to parameters either by env. vars. or 
function arguments allowing both compat. with 12-factor app approach, as 
well as attempting to encourage a functional programming model where you 
should ideally be unaware of any system environment.

Kind regards,
Matt 




From:   Martin Henke 
To: dev@openwhisk.apache.org
Date:   07/03/2019 09:29 AM
Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top 
of Knative



Michele,

FYI: Sugandha and myself published a Medium blog article which describes 
to build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related Knative 
work.

Link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0&s=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454&e=
 


Regards,
Martin


On 2019/05/20 15:00:02, "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 schrie

Re: Re: A plan to (re) implement OpenWhisk on top of Knative

[Martin Henke]

Hi Matt,

I fully agree with your thoughts. We should definitely (stepwise) aim for an 
unified model for all runtimes.

Regards,
Martin

> On 3. Jul 2019, at 16:43, Matt Rutkowski  wrote:
> 
> Hi Martin, 
> 
> It is my belief that Michele, now freshly returned from book editing 
> (congrats), was going to implement the same interface for pre/post 
> processing requests that we implemented for NodeJS.  This would allow us a 
> path to support this across all language runtimes as well as formalize our 
> runtime contract that aligns with a Knative Service approach and then also 
> allows us to better explore some of the use cases being discussed on 
> another thread from Rodric.  I believe that we should look at smaller 
> steps towards that alignment like removing the need for the "init" 
> entrypoint and allowing access to parameters either by env. vars. or 
> function arguments allowing both compat. with 12-factor app approach, as 
> well as attempting to encourage a functional programming model where you 
> should ideally be unaware of any system environment.
> 
> Kind regards,
> Matt 
> 
> 
> 
> 
> From:   Martin Henke 
> To: dev@openwhisk.apache.org
> Date:   07/03/2019 09:29 AM
> Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top 
> of Knative
> 
> 
> 
> Michele,
> 
> FYI: Sugandha and myself published a Medium blog article which describes 
> to build Nodejs10 images using Tekton and run it on Knative
> (based on the work from Priti).
> It might be on interest in the context of your Actionloop related Knative 
> work.
> 
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0&s=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454&e=
>  
> 
> 
> Regards,
> Martin
> 
> 
> On 2019/05/20 15:00:02, "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

Re: Re: A plan to (re) implement OpenWhisk on top of Knative

[Matt Rutkowski]

Hi Martin, 

It is my belief that Michele, now freshly returned from book editing 
(congrats), was going to implement the same interface for pre/post 
processing requests that we implemented for NodeJS.  This would allow us a 
path to support this across all language runtimes as well as formalize our 
runtime contract that aligns with a Knative Service approach and then also 
allows us to better explore some of the use cases being discussed on 
another thread from Rodric.  I believe that we should look at smaller 
steps towards that alignment like removing the need for the "init" 
entrypoint and allowing access to parameters either by env. vars. or 
function arguments allowing both compat. with 12-factor app approach, as 
well as attempting to encourage a functional programming model where you 
should ideally be unaware of any system environment.

Kind regards,
Matt 




From:   Martin Henke 
To: dev@openwhisk.apache.org
Date:   07/03/2019 09:29 AM
Subject:[EXTERNAL] Re: A plan to (re) implement OpenWhisk on top 
of Knative



Michele,

FYI: Sugandha and myself published a Medium blog article which describes 
to build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related Knative 
work.

Link:
https://urldefense.proofpoint.com/v2/url?u=https-3A__medium.com_-40sugandha.agrawal18_build-2Dknative-2Dservice-2Dwith-2Dtekton-2Dand-2Dapache-2Dopenwhisk-2Dnode-2Djs-2Druntime-2Df660bbc3a11e&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=6zQLM7Gc0Sv1iwayKOKa4_SFxRIxS478q2gZlAJj4Zw&m=bl7bwPaoiSE6fi0fyVHNC9bNUnh1ZUUlfl3lwUZbcH0&s=IQBGPfSTPiAjKhIlsqKDpAjoJBNd7By1YnjxOIx2454&e=
 


Regards,
Martin


On 2019/05/20 15:00:02, "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 som

Re: A plan to (re) implement OpenWhisk on top of Knative

[Sugandha Agrawal]

Cool!!!


Regards
Sugandha Agrawal




On Wed, Jul 3, 2019 at 4:37 PM Michele Sciabarra 
wrote:

> Thanks! Indeed it was my next step since I am now trying to build actions
> with the actionloop based runtime with tekton. I thought to use Priti work
> that has to be updated to use Tekton so your article is very welcome and
> useful.
>
> --
>   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: Wednesday, July 03, 2019 4:29 PM
>
> Michele,
>
> FYI: Sugandha and myself published a Medium blog article which describes
> to build Nodejs10 images using Tekton and run it on Knative
> (based on the work from Priti).
> It might be on interest in the context of your Actionloop related Knative
> work.
>
> Link:
>
> https://medium.com/@sugandha.agrawal18/build-knative-service-with-tekton-and-apache-openwhisk-node-js-runtime-f660bbc3a11e
>
> Regards,
> Martin
>
>
> On 2019/05/20 15:00:02, "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

Re: A plan to (re) implement OpenWhisk on top of Knative

[Michele Sciabarra]

Thanks! Indeed it was my next step since I am now trying to build actions with 
the actionloop based runtime with tekton. I thought to use Priti work that has 
to be updated to use Tekton so your article is very welcome and useful.

-- 
  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: Wednesday, July 03, 2019 4:29 PM

Michele,

FYI: Sugandha and myself published a Medium blog article which describes to 
build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related Knative work.

Link:
https://medium.com/@sugandha.agrawal18/build-knative-service-with-tekton-and-apache-openwhisk-node-js-runtime-f660bbc3a11e

Regards,
Martin


On 2019/05/20 15:00:02, "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.> 

Re: A plan to (re) implement OpenWhisk on top of Knative

[Martin Henke]

Michele,

FYI: Sugandha and myself published a Medium blog article which describes to 
build Nodejs10 images using Tekton and run it on Knative
(based on the work from Priti).
It might be on interest in the context of your Actionloop related Knative work.

Link:
https://medium.com/@sugandha.agrawal18/build-knative-service-with-tekton-and-apache-openwhisk-node-js-runtime-f660bbc3a11e

Regards,
Martin


On 2019/05/20 15:00:02, "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 Kn

[slack-digest] [2019-07-02] #general

[OpenWhisk Team Slack]

2019-07-02 06:59:21 UTC - Rob Allen: Dunno if anyone is able to point Allan at 
some useful docs? 
 at
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562050761118300?thread_ts=1562050761.118300&cid=C3TPCAQG1

2019-07-02 07:01:56 UTC - chetanm: May be standalone mode would be useful here. 
Commented on the thread
+1 : Rob Allen, Dominic Kim
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562050916118500?thread_ts=1562050761.118300&cid=C3TPCAQG1

2019-07-02 07:26:12 UTC - Dominic Kim: Are you guys aware that we can trace all 
OW invocation with 
Pinpoint()?
My team recently contributed the OpenWhisk plugin and Akka-http plugin to the 
project.
+1 : keonhee Kim, Jiang PengCheng, chetanm, Rodric Rabbah
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562052372120500

2019-07-02 07:26:27 UTC - Dominic Kim: You guys can get something similar to 
this:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562052387120900

2019-07-02 07:26:45 UTC - Dominic Kim: 
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562052405121000

2019-07-02 07:28:26 UTC - Dominic Kim: I took screenshots from my in-house 
version and please bear with some blurred parts and differences in the server 
map.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562052506122900

2019-07-02 07:28:58 UTC - Dominic Kim: But you can setup the same thing with 
the current upstream master and Pinpoint.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562052538123500

2019-07-02 08:00:02 UTC - James Thomas: wow neat!
grinning : Dominic Kim
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562054402124100

2019-07-02 08:00:11 UTC - James Thomas: you should blog about that @Dominic Kim
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562054411124400

2019-07-02 08:00:12 UTC - James Thomas: :slightly_smiling_face:
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562054412124600

2019-07-02 09:13:03 UTC - Dominic Kim: @James Thomas Thanks 
:slightly_smiling_face: Do you mean blogging to OpenWhisk blog? or a personal 
blog?
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562058783125800

2019-07-02 09:14:33 UTC - Dominic Kim: I think I can ask the one who mainly did 
it to blog it. : )
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562058873126500

2019-07-02 09:19:50 UTC - James Thomas: if you publish on medium - we can put 
it on the OW blog?
white_check_mark : Dominic Kim
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562059190126800

2019-07-02 09:20:05 UTC - Dominic Kim: got it.
https://openwhisk-team.slack.com/archives/C3TPCAQG1/p1562059205127100

2019-07-02 13:36:19 UTC - Michael Schmidt: Hi I am attempting to use the 
serverless libraries with OpenWhisk. I have successfully tried out the nodejs

I have a bug to report with the python2 (let me know where the best place for 
this is):
```
serverless create --template openwhisk-python --path pyhton-test
#creates project successfully, but then when you try to deploy you get the 
following error
```
```
serverless deploy -v
Serverless: Packaging service...
Serverless: Excluding development dependencies...
Serverless: Compiling Functions...
Serverless: Compiled Function (tryme): 
{"actionName":"pyhton-test-dev-tryme","overwrite":true,"action":{"exec":{"main":"tryme","kind":"python","code":""},"limits":{"timeout":6,"memory":256,"concurrency":1},"parameters":[],"annotations":[]}}
Serverless: Compiling Packages...
Serverless: Compiling API Gateway definitions...
Serverless: Compiling Rules...
Serverless: Compiling Triggers & Feeds...
Serverless: Compiling Service Bindings...
Serverless: Deploying Functions...
Serverless: Deploying Function: pyhton-test-dev-tryme

  Serverless Error ---

  Failed to deploy function (pyhton-test-dev-tryme) due to error: PUT 

 Returned HTTP 400 (Bad Request) --> "The request content was malformed:
kind 'python' not in Set(dotnet:2.2, go:1.11, nodejs:10, ballerina:0.990, 
ruby:2.5, nodejs:8, blackbox, java, swift:4.2, sequence, nodejs:6, nodejs:12, 
python:3, python:2, php:7.3)"

  Get Support 
 Docs:  
 Bugs:  

 Issues:

  Your Environment Information ---
 OS: linux
 Node Version:   6.17.1
 Serverless Version: 1.46.1

```
After editing the serverless yaml to python:2 things worked just fine

I am now having trouble with setting up python3 via the same method, but