Note further that for actions that aren't intrinsic that making is isomorphic with these proposed changes.
-r > On Mar 5, 2017, at 2:52 PM, Alex Glikson <[email protected]> wrote: > > Good direction! > > How about taking this one step further and removing "kind" from the API > altogether, leaving just "image", "code" (text or binary) and "main"? We > could manage the kind-->image mapping on the client side. > > Regards, > Alex > > > > > From: Rodric Rabbah <[email protected]> > To: [email protected] > Date: 05/03/2017 06:39 PM > Subject: factoring out "runtimes" into deployment configuration > > > > 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 > > > >
