openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Glikson" <GLIK...@il.ibm.com>
Subject Re: factoring out "runtimes" into deployment configuration
Date Sun, 05 Mar 2017 21:10:34 GMT
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: glikson@il.ibm.com | Skype: alex.glikson | Phone: +972-4-8281085 | 
Mobile: +972-54-6466667




From:   Rodric Rabbah <rodric@gmail.com>
To:     dev@openwhisk.apache.org
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 <GLIKSON@il.ibm.com> wrote:
> 
> Don't (or at least can't) they run in Docker containers too?
> 
> Alex
> 
> 
> 
> From:   Rodric Rabbah <rodric@gmail.com>
> To:     dev@openwhisk.apache.org
> 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 <GLIKSON@il.ibm.com> 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 <rodric@gmail.com>
>> To:     dev@openwhisk.incubator.apache.org
>> 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
>> 
>> 
>> 
>> 
> 
> 
> 
> 
> 






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