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 <[email protected]> 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 <[email protected]> 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 >>
