The sequence doesn't run in a container. It's more an continuation style activation. Its components do, of course. So abstractly it's an action but there is no code to execute in a container for the sequence itself.
-r > On Mar 5, 2017, at 3:41 PM, Alex Glikson <[email protected]> wrote: > > Don't (or at least can't) they run in Docker containers too? > > Alex > > > > From: Rodric Rabbah <[email protected]> > To: [email protected] > Date: 05/03/2017 09:59 PM > Subject: Re: factoring out "runtimes" into deployment configuration > > > > I considered that but it would be at odds with actions that have no images > - in particular sequences and other combinators in the future. > > -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 >> >> >> >> > > > > >
