You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwhisk.apache.org by Tyson Norris <tn...@adobe.com.INVALID> on 2017/08/16 18:03:02 UTC

Releases and SPI plans

Hi -
Per the call earlier today, here is a summary of what was discussed regarding SPI extensions and releases:

- contributing extensions: extensions (SPI impls) can be contributed either
- within OW codebase directly
- within separate repos
- to contribute via OW codebase
- OW build can include multiple SPI impls, a specific one is enabled at runtime by config
- NOTE: SPI impl evolution will be managed as part of OW build and release process
- to contribute via separate repos, we need:
- release maven artifacts of SPI interfaces, including entities that may be leveraged by the SPI impl
- provide a convention for building docker images that have the additional SPI impls added
- NOTE: SPI impl evolution will be DECOUPLED from the OW build and release process

Some action items required:
- define which SPI interfaces should be released as a mvn artifact (these will become stable interfaces that require more/better lifecycle management, deprecation, etc)
- plans for a “release process” should be extended to include mvn artifact of this set of SPI interfaces
(an initial proposal for release process is here: https://cwiki.apache.org/confluence/display/OPENWHISK/OpenWhisk+Release+Process)
- as part of defining which SPI interfaces are required, an additional set of SPI extension points that address specific near term requirements should be considered, including:
- loadbalancer - pending PR #2584
- multi-loadbalancer - to allow routing activations to different types of execution resource pools (e.g. concurrent vs queued execution or short timeout vs long timeout execution etc)
- container factory - to delegate container lifecycle management to cluster managers (kube, mesos, etc)
- logging - to delegate log collection and access (required when container factory does not have access to container logs directly)
- authentication - to support additional auth mechanisms at the server side (and advertise supported mechanisms to clients)

Please chime in if you have comments!

Thanks
Tyson