openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <>
Subject Re: Concurrency PR
Date Mon, 20 Aug 2018 16:34:52 GMT

To better handle the case of images that don’t support concurrency, or
don’t support log collection from invoker, I would suggest we change the
container protocol to allow containers to broadcast their support either
via the /init endpoint, or via a new /info endpoint. This of course would
not give feedback until an action is executed (as opposed to when action is
created), but I think this is ok. I will work on a separate PR for this,
but want to mention some thoughts here about possible approaches to address
these known concerns.

Why not make this part of the runtimes manifest? Handling this as late as
actually invoking the action feels kinda weird if we can just as well know
ahead of time, that creating an action with a concurrency > 1 will not work
and should therefore forbid creation at all. Any strong reason not to
encode that information into the runtimes manifest?

One thing is blackbox containers - will only managed containers be allowed to support concurrency?
If not, how will blackbox containers advertise support?

Separately, the only thing that action creation currently does is validate “action build
time” issues, like "do action limits fit within the allowed ranges”, it does not mean
the input value is appropriate for execution. If the runtime manifest had per-image settings
for all action limits, it would make more sense to include concurrency there - but I would
have the same suggestion, that allowing the image to dictate the entirety of its opinions
on these allowed ranges would be nicer to do as part of the container protocol (/init, /run),
and not the manifest - partly for blackbox support, and partly because it is simpler to maintain
just the image and just the manifest (which just references images, not the metadata of what
the image supports internally).

In any case, is this (per container metadata indicating concurrency support) really required
for supporting concurrency at all? I agree it will be nice, but don’t think that it should
block adding support for concurrency.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message