openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyson Norris <tnor...@adobe.com.INVALID>
Subject Releases and SPI plans
Date Wed, 16 Aug 2017 18:03:02 GMT
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






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