openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Re: Pluggable components in OpenWhisk
Date Thu, 22 Jun 2017 18:00:44 GMT
Following up on this thread, I just created this PR to propose an SPI approach for making OW
internal components pluggable, with examples of db + messaging (using existing impls as defaults
so no change in functionality). This does NOT address any potential class path changes to
include additional/alternate impls, it is ONLY the support for loading the impls, so that
classpath can be changed in the future. Some description of the model and discussion of classpath
modification options is included in the docs/spi.md file.

https://github.com/apache/incubator-openwhisk/pull/2414

It has evolved in various ways from my original proposal, but hopefully a usable example will
be a better demonstration of the approach.

Thanks in advance for feedback.

Tyson


On Jun 14, 2017, at 6:43 AM, Rodric Rabbah <rodric@gmail.com<mailto:rodric@gmail.com>>
wrote:

I saw that class and I just wanted to check if a contribution would be
accepted eventually.

We are generally tending toward a model where the components are all
deployment time configurable so that one can tailor the architecture to use
or experiment with different technology. The datastore has an abstract
interface, the message bus producer and consumer also has an abstract
interface, we recently refactor the interface to the container pool
management, and there's ongoing discussion about logging and tracing in the
same way. These abstractions were intended to allow for experimentation and
with the right model for plugins, I think we can address the increasing
interest we are observing in making the architecture adaptable in several
ways.

On the message bus, Kafka makes sense because it offers low latency
messaging and offers persistence of the activation requests. That said, I
expect this is will be an area of continued interest as it has implication
for the load balancing and scheduling.

-r


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