> 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 >
