So, maybe we just need two "kinds" at the moment - 'regular' action (with image and code, plus whatever 'syntactic sugar' we want at the client side) and 'sequence' (with 'components'). Excluding sequences, what else is controller currently doing with 'kind' besides selecting the image? Now that 'blackbox' actions can be used to run 'native' language actions equally (?) well, it feels redundant to have two args in the API used for the same purpose.
Regards, Alex =========================================================================== Alex Glikson Senior Researcher, Cloud Platforms, IBM Research - Haifa; IBM Lead for FIWARE Email: [email protected] | Skype: alex.glikson | Phone: +972-4-8281085 | Mobile: +972-54-6466667 From: Rodric Rabbah <[email protected]> To: [email protected] Date: 05/03/2017 10:54 PM Subject: Re: factoring out "runtimes" into deployment configuration 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 >> >> >> >> > > > > >
