openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dascalita Dragos <ddrag...@gmail.com>
Subject Re: factoring out "runtimes" into deployment configuration
Date Thu, 09 Mar 2017 22:43:49 GMT
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 <mmarth@adobe.com> 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" <rodric@gmail.com<mailto:
> rodric@gmail.com>> 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
>
>

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