openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dascalita Dragos <ddrag...@gmail.com>
Subject Re: factoring out "runtimes" into deployment configuration
Date Fri, 10 Mar 2017 00:46:21 GMT
I was thinking we could avoid the zip.

On Thu, Mar 9, 2017 at 4:13 PM Rodric Rabbah <rodric@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message