openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Thömmes <>
Subject Re: Kafka and Proposal on a future architecture of OpenWhisk
Date Thu, 23 Aug 2018 22:27:26 GMT

Am Fr., 24. Aug. 2018 um 00:07 Uhr schrieb Tyson Norris

>     > Router is not pulling at queue for "specific actions", just for any
> action
>     > that might replace idle containers - right? This is complicated with
>     > concurrency though since while a container is not idle (paused +
>     > removable), it may be useable, but only if the action received is
> the same
>     > as one existing warm container, and that container has concurrency
> slots
>     > available for additional activations. It may be helpful to diagram
> some of
>     > this stealing queue flow a bit more, I'm not seeing how it will work
> out
>     > other than creating more containers than is absolutely required,
> which may
>     > be ok, not sure.
>     >
>     Yes, I will diagram things out soonish, I'm a little bit narrow on time
>     currently.
>     The idea is that indeed the Router pulls for *specific* actions. This
> is a
>     problem when using Kafka, but might be solvable when we don't require
>     Kafka. I have to test this for feasibility though.
> Hmm OK - it's not clear how a router that is empty (not servicing any
> activations) becomes a router that is pulling for that specific action,
> when other routers pulling for that action are at capacity (so new
> containers are needed)

Disclaimer: All of this is very much in the idea and not part of the
original proposal.

That's where the second part of the "idea" that I had above comes in: If we
can somehow detect, that nobody is pulling (all are at capacity or have no
container), that is then the moment where we need to create new containers.

I proposed further above in the discussion that the Routers do *not* ask
for more Containers but rather that signal of the MQ (hey, nobody is having
capacity for that action apparently... so let's create capacity) could be
used to create Containers.

That's a very blunt assumption though, I don't know if that's feasible at
all. There might be a performant way of implementing just that signal in a
distributed way though (the signal being: We are out of capacity over the
whole cluster, we need more). A second idea that comes to my mind would be
to implement a shared counter (it can easily be eventually consistent,
consistency is I think not a concern here). Once that counter drops to 0 or
below 0, we need more Containers.

This is I think were the prototyping thread comes in: Personally, I don't
feel comfortable stating that any of the approaches outlined by me really
do work without having tried it out.

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