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
