openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Pluggable components in OpenWhisk
Date Fri, 09 Jun 2017 23:54:34 GMT
Hi -
I’ve seen the need for portions of OpenWhisk to be more “pluggable”, and seen similar
comments in GitHub and dev list.

Some areas I think are worthy of discussion are:
- tracing
- logging
- container management (docker, runc, mesos, swarm, kubernets)
- persistence (couchdb)
- messaging (Kafka) (I haven’t heard any suggestions here, but it wouldn’t surprise me)

To make any progress on anything being pluggable, one approach is to provide a convention
for doing the plugging.

Toward this, I put together a simple SPI style wrapper around akka extensions and ServiceLoader,
so that:
- its easy to consume, for the app (adding well defined SPIs), and the impl builders (providing
additional SPI impls
- its easy (and clean) to configure: no unused jars in your classpath, no guessing at which
impl is loaded at runtime, etc

Here is a stripped down example:
https://github.com/tysonnorris/akka-spi

My suggested way forward would be:
- if this approach seems useful, I’ll create a PR to merge the utility classes (see spi-core)
into OW master
- once the utilities for this approach are in master, create another PR for a specific proposed
SPI, which would 1) separate the SPI to a new directory and 2) provide the default impl of
that SPI.
- one an SPI is defined, additional impls can be added without disruption (and enabled optionally
in different envs).
- Once there are additional SPI impls available for a specific SPI, it MIGHT become important
to define an approach for building classpathes for the OW runtimes where only specific SPI
impls arrive on the classpath; I haven’t considered how to do this at this point.

Thanks
Tyson

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