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 >> >>
