openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <>
Subject Re: factoring out "runtimes" into deployment configuration
Date Tue, 07 Mar 2017 12:20:41 GMT
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)?



On 05/03/17 17:39, "Rodric Rabbah" <<>>

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

In support of this general direction (even if we settle on a different
approach), I have increasingly flattened the "Exec" type hierarchy in the


A sketch of how to use the runtime manifest can be seen in this WIP commit:

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message