You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Rodric Rabbah <ro...@gmail.com> on 2019/03/15 04:49:13 UTC
override main on activation?
When one creates an action today, they can specify the main entry point at
creation time. For example:
wsk action create myfn f.js --main foo
This allows a single file with multiple functions to be used as different
actions.
But this is wasteful - one has to create multiple actions this way and
we're paying the cost in the backend by replicating the code (in the
database, and multiple code fetches).
What if the main was specified on invoke instead? For example, take a web
action from this file hello.js
function niam(args) { return { 'greetings': 'Hello from a
non-standard entrypoint.' } } function main(args) { return {
'greetings': 'Hello from a standard entrypoint.' } }
We could allow main to be set on the action activation.
> curl -k https://guest.localhost/default/hello.json
{
"greetings": "Hello from a standard entrypoint."
}
And now with an override to "main", using @<new main> as the new entry
point.
> curl -k https://guest.localhost/default/hello.json@niam
{
"greetings": "Hello from a non-standard entrypoint."
}
I created an issue to discuss the idea [1].
I'm thinking primarily to restrict this to web actions initially, although
there are some extensions that are also reasonable to consider subsequently:
1. we could also make it work for POST invoke, namely wsk action invoke
--main.
2. we can extend it to sequences so that you can create a sequence from
fn@main1, fn@main2
3. we can further extend it to conductor continuations
[1] https://github.com/apache/incubator-openwhisk/issues/4349
Re: override main on activation?
Posted by Carlos Santana <cs...@gmail.com>.
I'm guessing you already tried passing the name of the function as
parameter and got "is not a function" :-)
function man(param) { param["main"](param) }
At least for me I consider best practice to users to avoid packaging into a
single file/zip multiple functions
I think OpenWhisk gave a good architecture constraint to adhere to the
single responsibility rule
In OpenWhisk terms an action should have one function, which with web
action gives you a single endpoint url
This avoids for the most part a large monolith hybrid function where you
stuck a bunch of other functions into a single action package/deployment.
I like using a single action for a single purpose, and not sneak other
functions, because if I have to path it or quick fix, I know the change to
the action code/zip only affects the function with the bug and not the
other functions I snuck :-)
Creating multiple actions and endpoints should be cheap and easy.
With that said, I realize when I create applications with OpenWhisk and
create multiple actions, the multiple zips (because I like packaged actions
!) there is a lot of duplication
This duplications come from my own utility common code across the actions,
and a bunch of npm packages that I use across the actions.
But I would like a better UX to void burning so many bandwidth sending the
same bytes of common code as an user, as a vendor/provider I would not like
to pay for the duplicate storage I give users for free Yay!
Pigging back on what James said about using S3/COS, and also something that
we have discuss in the past in Slack with folks like Michael Marth from
Adobe.
It would be awesome if I can have some tooling that allows me to deploy to
S3/COS and then tell OpenWhisk about it.
For example (here are the mechanics, not necessary how it get's expose to
end user:
Deploy an object to S3 with my common utils code maybe is a tgz
/mybucket/app1-common-v1.tgz
Deploy an object to S3 with my npm packages maybe is a tgz using the
command "npm pack" /mybucket/app1-dependencies-v1.tgz
This two artifacts I don't have to deploy them from my laptop for a while
as they don't change that much,
Now I can deploy my actions to S3
/mybucket/app1-action-task1-single-source-v1.js
/mybucket/app1-action-niam-multifilesource-v1.tgz
An an user maybe I never see S3, maybe I just see the wsk CLI, or wsk
deploy and a manifest, maybe this tools or provider takes care for me to
deploy and manage the S3, or if I want to go raw I deploy to S3
like:
wsk action update package app1 --layer mybucket/app1-common-v1.tgz --dep
bucket/app1-dependencies-v1.tgz
wsk action update action app1/task1 app1-action-task1-single-source-v1.js
wsk action update action app1/func21
app1-action-niam-multifilesource-v1.tgz --kind nodejs:10
Just wanted to give my POV that we don't throw the baby with the bathwater,
also that incremental improvements are fine as long they are not hack
shortcuts in other direction.
Not saying this is shortcut for this the case, but just in case the counter
argument is:
"This awesome and nice but it would take a lot of work, can we do this
short term solutions for now because we already do things today that brake
the single responsibility principle anyway"
my two cents.
PS: Don't going to block a PR that adds this .json@<otherfunction>, going
to assume is also applicable to .http and .html?
-- Carlos
On Fri, Mar 15, 2019 at 6:58 AM James Thomas <jt...@gmail.com> wrote:
> This is an interesting idea. Lambda has a nice feature of being able to
> create functions from an S3 file containing the source zip, which means you
> don't have to upload the same code for each different function. Not having
> something can make deployments unnecessarily long on OpenWhisk when you
> have a large app with dozens of functions and large action packages.
>
> If this was available - I wonder if there's a way to define an "action
> clone" which is like a sym-link to another action with a different "main"
> parameter (defined at create time)? It would allow us to upload the action
> package once and then create sym-links for all the other actions. This
> would dramatically speed up deployments and reduce the amount of code
> needed to store in the backend.
>
>
>
>
> On Fri, 15 Mar 2019 at 07:45, Michele Sciabarra <mi...@sciabarra.com>
> wrote:
>
> > I like the idea. In particular, it would be very helpful in implementing
> > an idea I had some time ago: deployment of Jupyter Notebooks as actions!
> > (Here I refer to Python based notebooks mostly)
> >
> > Normally you have some code in it that you develop (and test)
> > interactively, but the problem is: what is the entry point? Of course, it
> > would be a "main" action defined in it but it would be limiting.
> >
> > In this way, I could pass the entire notebook to the initialization of
> the
> > action and then invoke the various functions defined in it.
> >
> > --
> > Michele Sciabarra
> > michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Rodric Rabbah <ro...@gmail.com>
> > To: dev@openwhisk.apache.org
> > Subject: override main on activation?
> > Date: Friday, March 15, 2019 5:58 AM
> >
> > When one creates an action today, they can specify the main entry point
> at
> > creation time. For example:
> >
> > wsk action create myfn f.js --main foo
> >
> > This allows a single file with multiple functions to be used as different
> > actions.
> >
> > But this is wasteful - one has to create multiple actions this way and
> > we're paying the cost in the backend by replicating the code (in the
> > database, and multiple code fetches).
> >
> > What if the main was specified on invoke instead? For example, take a web
> > action from this file hello.js
> >
> > function niam(args) { return { 'greetings': 'Hello from a
> > non-standard entrypoint.' } } function main(args) { return {
> > 'greetings': 'Hello from a standard entrypoint.' } }
> >
> > We could allow main to be set on the action activation.
> >
> > > curl -k https://guest.localhost/default/hello.json
> > {
> > "greetings": "Hello from a standard entrypoint."
> > }
> >
> > And now with an override to "main", using @<new main> as the new entry
> > point.
> >
> > > curl -k https://guest.localhost/default/hello.json@niam
> > {
> > "greetings": "Hello from a non-standard entrypoint."
> > }
> >
> > I created an issue to discuss the idea [1].
> >
> > I'm thinking primarily to restrict this to web actions initially,
> although
> > there are some extensions that are also reasonable to consider
> > subsequently:
> >
> > 1. we could also make it work for POST invoke, namely wsk action
> invoke
> > --main.
> > 2. we can extend it to sequences so that you can create a sequence
> from
> > fn@main1, fn@main2
> > 3. we can further extend it to conductor continuations
> >
> > [1] https://github.com/apache/incubator-openwhisk/issues/4349
> >
>
>
> --
> Regards,
> James Thomas
>
--
Carlos Santana
<cs...@gmail.com>
Re: override main on activation?
Posted by James Thomas <jt...@gmail.com>.
This is an interesting idea. Lambda has a nice feature of being able to
create functions from an S3 file containing the source zip, which means you
don't have to upload the same code for each different function. Not having
something can make deployments unnecessarily long on OpenWhisk when you
have a large app with dozens of functions and large action packages.
If this was available - I wonder if there's a way to define an "action
clone" which is like a sym-link to another action with a different "main"
parameter (defined at create time)? It would allow us to upload the action
package once and then create sym-links for all the other actions. This
would dramatically speed up deployments and reduce the amount of code
needed to store in the backend.
On Fri, 15 Mar 2019 at 07:45, Michele Sciabarra <mi...@sciabarra.com>
wrote:
> I like the idea. In particular, it would be very helpful in implementing
> an idea I had some time ago: deployment of Jupyter Notebooks as actions!
> (Here I refer to Python based notebooks mostly)
>
> Normally you have some code in it that you develop (and test)
> interactively, but the problem is: what is the entry point? Of course, it
> would be a "main" action defined in it but it would be limiting.
>
> In this way, I could pass the entire notebook to the initialization of the
> action and then invoke the various functions defined in it.
>
> --
> Michele Sciabarra
> michele@sciabarra.com
>
> ----- Original message -----
> From: Rodric Rabbah <ro...@gmail.com>
> To: dev@openwhisk.apache.org
> Subject: override main on activation?
> Date: Friday, March 15, 2019 5:58 AM
>
> When one creates an action today, they can specify the main entry point at
> creation time. For example:
>
> wsk action create myfn f.js --main foo
>
> This allows a single file with multiple functions to be used as different
> actions.
>
> But this is wasteful - one has to create multiple actions this way and
> we're paying the cost in the backend by replicating the code (in the
> database, and multiple code fetches).
>
> What if the main was specified on invoke instead? For example, take a web
> action from this file hello.js
>
> function niam(args) { return { 'greetings': 'Hello from a
> non-standard entrypoint.' } } function main(args) { return {
> 'greetings': 'Hello from a standard entrypoint.' } }
>
> We could allow main to be set on the action activation.
>
> > curl -k https://guest.localhost/default/hello.json
> {
> "greetings": "Hello from a standard entrypoint."
> }
>
> And now with an override to "main", using @<new main> as the new entry
> point.
>
> > curl -k https://guest.localhost/default/hello.json@niam
> {
> "greetings": "Hello from a non-standard entrypoint."
> }
>
> I created an issue to discuss the idea [1].
>
> I'm thinking primarily to restrict this to web actions initially, although
> there are some extensions that are also reasonable to consider
> subsequently:
>
> 1. we could also make it work for POST invoke, namely wsk action invoke
> --main.
> 2. we can extend it to sequences so that you can create a sequence from
> fn@main1, fn@main2
> 3. we can further extend it to conductor continuations
>
> [1] https://github.com/apache/incubator-openwhisk/issues/4349
>
--
Regards,
James Thomas
Re: override main on activation?
Posted by Michele Sciabarra <mi...@sciabarra.com>.
I like the idea. In particular, it would be very helpful in implementing an idea I had some time ago: deployment of Jupyter Notebooks as actions! (Here I refer to Python based notebooks mostly)
Normally you have some code in it that you develop (and test) interactively, but the problem is: what is the entry point? Of course, it would be a "main" action defined in it but it would be limiting.
In this way, I could pass the entire notebook to the initialization of the action and then invoke the various functions defined in it.
--
Michele Sciabarra
michele@sciabarra.com
----- Original message -----
From: Rodric Rabbah <ro...@gmail.com>
To: dev@openwhisk.apache.org
Subject: override main on activation?
Date: Friday, March 15, 2019 5:58 AM
When one creates an action today, they can specify the main entry point at
creation time. For example:
wsk action create myfn f.js --main foo
This allows a single file with multiple functions to be used as different
actions.
But this is wasteful - one has to create multiple actions this way and
we're paying the cost in the backend by replicating the code (in the
database, and multiple code fetches).
What if the main was specified on invoke instead? For example, take a web
action from this file hello.js
function niam(args) { return { 'greetings': 'Hello from a
non-standard entrypoint.' } } function main(args) { return {
'greetings': 'Hello from a standard entrypoint.' } }
We could allow main to be set on the action activation.
> curl -k https://guest.localhost/default/hello.json
{
"greetings": "Hello from a standard entrypoint."
}
And now with an override to "main", using @<new main> as the new entry
point.
> curl -k https://guest.localhost/default/hello.json@niam
{
"greetings": "Hello from a non-standard entrypoint."
}
I created an issue to discuss the idea [1].
I'm thinking primarily to restrict this to web actions initially, although
there are some extensions that are also reasonable to consider subsequently:
1. we could also make it work for POST invoke, namely wsk action invoke
--main.
2. we can extend it to sequences so that you can create a sequence from
fn@main1, fn@main2
3. we can further extend it to conductor continuations
[1] https://github.com/apache/incubator-openwhisk/issues/4349