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
