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 handle *popular* images, rather than a hard-coded set of "native" kind images. This would eliminate the performance overhead.
Regards, Alex P.S. Once we do #1 and #2 above, my claim is that we don't need pre-defined set of "kind" images any more, and just need a flexible hierarchy of images that anyone can reuse and extend Markus Thömmes <[email protected]> wrote on 10/03/2017 12:48:17 AM: > From: Markus Thömmes <[email protected]> > To: [email protected] > Date: 10/03/2017 12:48 AM > Subject: Re: factoring out "runtimes" into deployment configuration > > 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 to do something similar). Note though that the same > performance implications as with blackbox images apply. > > Von meinem iPhone gesendet > > > Am 09.03.2017 um 23:43 schrieb Dascalita Dragos <[email protected]>: > > > > 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 thinking at the use-case when a package with a group of actions > > requires multiple libraries for each action. To simplify my example I'm > > going to refer only to JS actions: > > - Today: when actions needs extra libs users have 2 options : > > a) create a zip > > b) browserify/"compile" JS into a single JS file > > - What I'm thinking: allow users to create their own "runtime" image > > where they can bundle those dependent libs into. All the actions in the > > package would be smaller, they would use less space and would probably flow > > easier through the system when being invoked. A potential problem in this > > case would be whether it's secure to let users push their own images in the > > OW nodes, but at the same time allowing them to upload a ZIP is > > conceptually also a "package"/"container" that can contain anything; I > > guess the security aspect would still remain even with user-defined > > containers. > > > > Dragos > > > > > > > >> On Tue, Mar 7, 2017 at 4:20 AM Michael Marth <[email protected]> wrote: > >> > >> Hi Rodric, > >> > >> I think that?s great. > >> > >> Only comment (more to Matt than you): > >> If the runtimes are dynamic by deployment (and of course over time) this > >> probably should be reflected in the packaging format spec [1]. > >> (see also previous comment [2]:) > >> > >> - line 252: not sure if the list of runtime names should be in the > >> normative > >> section of a spec, because (as you also write) this list will fluctuate > >> between > >> deployments and over time. OTOH there should be established well known > >> names for > >> well-known runtimes. Maybe point to a community-curated, separate markdown > >> file > >> (where new entries get a PR that can be voted upon)? > >> > >> Cheers > >> Michael > >> > >> [1] > >> https://github.com/openwhisk/openwhisk-wskdeploy/blob/master/ > specification/openwhisk_v0.8.pdf > >> [2] http://markmail.org/message/pa35wxxl52tvbfxc > >> > >> > >> > >> On 05/03/17 17:39, "Rodric Rabbah" <[email protected]<mailto: > >> [email protected]>> wrote: > >> > >> I've been thinking about how we can add more action runtimes more easily - > >> without changing the backend (API, controller, invoker, CLI). One way I'm > >> leaning toward and started prototyping to get a better understanding of the > >> feasibility is to strip all runtime types from the backend (and CLI) and > >> encode the information about what action runtimes the system supports > >> through configuration parameters. > >> > >> This will make it possible to decouple deploying the core components from > >> managing the action runtime images. An example of encoding the runtime > >> information in a deployment configuration is > >> https://github.com/openwhisk/openwhisk/pull/1948. > >> > >> In support of this general direction (even if we settle on a different > >> approach), I have increasingly flattened the "Exec" type hierarchy in the > >> backend[1-3] > >> > >> [1] https://github.com/openwhisk/openwhisk/pull/1938 > >> [2] https://github.com/openwhisk/openwhisk/pull/1942 > >> [3] https://github.com/openwhisk/openwhisk/pull/1911 > >> > >> A sketch of how to use the runtime manifest can be seen in this WIP commit: > >> > >> https://github.com/rabbah/openwhisk/commit/ > a8890abe51a3e7e6a34f96a46798de660583e36f > >> > >> I can see how using this we can add new versions of Node.js, python:3, and > >> other handy images by curating a list of these in a separate process. > >> > >> Feedback, as always, solicited and appreciated. > >> > >> -r > >> > >> >
