Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Alex Glikson
I can think of couple of ways to make what you called "kind-aware blackbox" actions more developer-friendly: 1. Support them in the CLI (i.e., supporting both "image" and "code" arguments). This would make the developer experience straightforard. 2. Generalize the caching/pooling mechanism to han

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Dascalita Dragos
I was thinking we could avoid the zip. On Thu, Mar 9, 2017 at 4:13 PM Rodric Rabbah wrote: > You can send a zip file to a docker container. So if the image is > openwhisk/dockerskeleton or openwhisk/swift3action it works as you'd > expect. In either case there's no docker pull. And this is doabl

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Rodric Rabbah
You can send a zip file to a docker container. So if the image is openwhisk/dockerskeleton or openwhisk/swift3action it works as you'd expect. In either case there's no docker pull. And this is doable today already. What am I missing from your explanation? -r On Mar 9, 2017, at 6:44 PM, Dascal

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Dascalita Dragos
> Isn't that what we call "blackbox" (docker) actions now? IIRC, with "blackbox", developers need to rebuild the image every time, push it to a registry then invoke the action: ``` wsk action create --docker my-blackbox container/name ``` What I was imagining is a case where developers still dep

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Rodric Rabbah
> Extending the thought: what if we allow users to specify a custom container name when creating / updating actions, in case users want to ? Isn't that what we call "blackbox" (docker) actions now? But in general - the reason for this work - is along these lines. Rather than having a small number

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Markus Thömmes
What you're referring to is basically a "kind-aware" blackbox action, where you get the easyness of injecting your code and the flexibility of using whatever you want in the image as long as the interface fits. I generally like the idea and brought it up as well once (i custom built a blackbox

Re: factoring out "runtimes" into deployment configuration

2017-03-09 Thread Dascalita Dragos
With the "runtimeManifest" property I'm wondering if we can also expose the name of the container image instead of having to compute it in the code ? Extending the thought: what if we allow users to specify a custom container name when creating / updating actions, in case users want to ? I'm think

Re: white-listing @apache.org for slack

2017-03-09 Thread Sergio Fernández
I'm already in, Thanks, Carlos. For the moment having @apache.org as allowed domain it's enough. We'll see... On Wed, Mar 8, 2017 at 6:35 PM, Carlos Santana wrote: > Sorry for not replying earlier. > > OpenWhisk Slack is open to any one you can get an invite here: > http://slack.openwhisk.org/