openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <rod...@gmail.com>
Subject Re: factoring out "runtimes" into deployment configuration
Date Fri, 10 Mar 2017 00:13:41 GMT
You can send a zip file to a docker container. So if the image is openwhisk/dockerskeleton
or openwhisk/swift3action it works as you'd expect. In either case there's no docker pull.
And this is doable today already. What am I missing from your explanation?

-r

On Mar 9, 2017, at 6:44 PM, Dascalita Dragos <ddragosd@gmail.com> wrote:

>> Isn't that what we call "blackbox" (docker) actions now?
> 
> IIRC, with "blackbox", developers need to rebuild the image every time,
> push it to a registry then invoke the action:
> ```
> wsk action create --docker my-blackbox  container/name
> ```
> 
> What I was imagining is a case where developers still deploy "code" but, in
> addition, they get to specify which "container" to use for executing that
> code. I.e.
> ```
> wsk action create my-action ./my-action.js --kind:container/name:tag
> ```
> Assuming that `container/name` extends an existing OW container.
> 
> Now that I'm thinking at this, I'd say that probably a more elegant
> solution would be for developers to describe the extra libs in the
> `manifest.yaml` then, at deploy time, a control-plane component of OW
> builds an optimized container to be used later when invoking the action ...
> not an easier option to implement though.
> 
> 
> 
> 
> On Thu, Mar 9, 2017 at 2:55 PM Rodric Rabbah <rodric@gmail.com> wrote:
> 
>>> Extending the thought: what if we allow users to specify a custom
>> container
>> name when creating / updating actions, in case users want to ?
>> 
>> Isn't that what we call "blackbox" (docker) actions now?
>> But in general - the reason for this work - is along these lines.
>> Rather than having a small number of fixed images per runtime,
>> we can support many more.
>> 
>> A concern however is that we don't want to incur docker pull costs for some
>> set of curated images (in the future, you can image that docker actions
>> come
>> with an explicit push operation at create time - but we're not there yet).
>> 
>> So by having an extensible list of images, it makes it easier to curate
>> action runtimes.
>> 
>> The scenario you describe otherwise is already supported (we know there are
>> users
>> who extend our nodejs base image with their own artifacts). This has the
>> benefit
>> of pulling in fewer layers.
>> 
>> -r
>> 

Mime
View raw message