I was thinking we could avoid the zip. On Thu, Mar 9, 2017 at 4:13 PM Rodric Rabbah <rod...@gmail.com> wrote:
> 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 <ddrag...@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 <rod...@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 > >> >
