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 <rod...@gmail.com<mailto:rod...@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
