OpenWhisk
OpenWhisk is an open source, distributed Serverless computing platform able to execute application logic (Actions) in response to events (Triggers) from external sources (Feeds) or HTTP requests governed by conditional logic (Rules). It provides a programming environment supported by a REST API-based Command Line Interface (CLI) along with tooling to support packaging and catalog services. Additionslly, it now provides options to host the platform components as Docker containers on various Container Frameworks such as Mesos, Kunernetes, and Compose.
Three most important issues to address in the move towards graduation:
- Est. release process for ZIP of source code
- Est. release process for Docker and other platform binaries
- Increase additional company and individual Contributors to maintain all project repos.
Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be aware of?
- It had been our intent to have Apache host our staging (and move it out of disparate private builds within various companies). However, INFRA indicates they only typically allocate 1 VM per project for use with demos and minor things. They indicate that typically a donation is in order (ala. Spark).
- The desire for this staging capability was expressed in the Incubator submission where we anticipated needing ~12 VMs to host each platform component and be able to load balance/schedule Functional code as part of the OpenWhisk Serverless (across multiple supported language runtimes). This would also be needed to effectively test auto-scaling/load balancing and container pools and to get accurate performance test measures.
- Formal hand-off of OpenWhisk trademark/logo from IBM needs to be executed; need to identify process for this.
How has the community developed since the last report?
- First substantive design changes allowing for Service Provider Interfaces (SPIs) developed within Apache community (dev list, WIki, etc.).
- Established bi-weekly Zoom "Technical Interchange" calls that have been well received.
- Complete videos posted to OW YouTube channel and detailed notes to our CWIKI.
- Kubernetes on OpenWhisk work hosted a few ad-hoc to continue design discussions (CWIKI has designs and comments) for how best to move away from Ansible deployments to self-configuring, autoscalable containers (for use in Kube, Mesos, Compose, etc.).
- Increased interest/list/Slack traffic in general due to experiment Kube work, as it is applicable to Mesos, etc.
- Increased community discussions (design topics, features) of substance moved to dev list.
How has the project developed since the last report?
- incubator-openwhisk Github stars: 1928
- incubator-openwhisk GitHub forks: 417
- Movement to become more "pluggable" via Service Provider Interfaces (SPI), several PRs that are ongoing.
- So far there are now interfaces for MessagingProvider.scala, ArtifactStoreProvider.scala and proposals for others such as LogStore, ContainerFactory, LoadBalancer,
- So far there are now interfaces for MessagingProvider.scala, ArtifactStoreProvider.scala and proposals for others such as LogStore, ContainerFactory, LoadBalancer,
Sig. PRs:
initial work on no root ansible #2669
- This allows to deploy with no sudo/root access. Significant to enable Kube/Mesos deployments.
- This allows to deploy with no sudo/root access. Significant to enable Kube/Mesos deployments.
Simplify Spi implementations. #2663
- Service Provider Interfaces (SPI) become more mature as patterns emerge.
- Healthy discussion/growth area for project to allow most components to become (eventually) pluggable (e.g., Log, Trace, Container build, Load Balancing, Scheduler, Routing, Message Queue, etc.)
- Apply standard scala formatting #2650
- Coding/linting standards debated/agreed to by community (and CI automated enforcement encoded)
- Coding/linting standards debated/agreed to by community (and CI automated enforcement encoded)
- Allow multiple controllers and invokers in local environments #2633
- implement a ContainerPool which is completely independent of the underlying container driver to facilitate testing and extensibility.
- More improvements to allow different pooling of invoker containers based upon different application use case (new ideas generated in community) including requirements for diff. scheduling/co-tenanting,/user responsiveness (http), etc. needs.
- implement a ContainerPool which is completely independent of the underlying container driver to facilitate testing and extensibility.
Sig. discussions (dev list):
- Release for OpenWhisk
- Releases and SPI plans
- OpenWhisk shell tool
- authentication models for openwhisk
- Performance tests for OpenWhisk
- Adaption of hosts-files
- Default handling for HTTP web actions
How would you assess the podling's maturity? Please feel free to add your own commentary.
[ ] Initial setup [X] Working towards first release [X] Community building
[ ] Nearing graduation [ ] Other:
Comments:
- Need greater variety of contributors and contributing companies
Date of last release:
- N/A
When were the last committers or PPMC members elected?
- Tyson Norris, Committer, 08/31/2017
- James Dubee, PPMC, Committer, 09/05/2017
Signed-off-by:
[ ](openwhisk) Felix Meschberger Comments: [ ](openwhisk) Isabel Drost-Fromm Comments: [ ](openwhisk) Sergio Fernández Comments:
IPMC/Shepherd notes: