Apache OpenWhisk Documentation

When a user uploads an action via the wsk CLI, the ActionLoop proxy prepares a work folder containing src and bin directories. The proxy handles different file types as follows:

• Executable file: Stored as bin/exec and executed directly.
• Non-executable/Non-zip file: Stored as src/exec, then the compilation script is invoked.
• ZIP file: Unzipped into the src folder.
  • If src/exec exists and is an executable, src is renamed to bin and bin/exec is executed.
  • If src/exec is missing or not an executable, the compilation script is invoked.

An executable for ActionLoop must be either a Linux binary (ELF) or a script starting with a shebang (e.g., #!/bin/bash).

OpenWhisk allows users to expose event producer services as feeds within a package. There are three primary architectural patterns for implementing a feed:

1. Hooks: The easiest method for low-frequency feeds. It uses a webhook facility from an external service to POST directly to an OpenWhisk trigger URL. No persistent external service is required.
2. Polling: An OpenWhisk action is configured to poll an endpoint periodically. This is easy to build but limited by the polling interval and is suitable for low-volume/low-latency requirements.
3. Connections: The highest performance option for high-volume feeds. It requires a separate, persistent provider service outside of OpenWhisk that maintains long-polling or push notification connections to the source and proxies events to OpenWhisk via its REST API.

To function as an OpenWhisk action, a function must meet these criteria:

• Input/Output: The function must accept a dictionary (JSON object) as input and produce a dictionary as output. Keys are strings, and values are any valid JSON types.
• Entry Point: The function must be named main or be explicitly exported. If using the wsk CLI, you can specify a different entry point using the --main flag.
• Statelessness: Functions should be stateless or idempotent. While containers may be reused (warm starts), there is no guarantee that state will persist across different invocations.

OpenWhisk provides two distinct categories of metrics:

1. System Metrics: Focus on system performance. These are intended for OpenWhisk providers or operators and can be sent to Kamon or written to log files in logmarker format.
2. User Metrics (Events): Focus on action performance. These are sent to Kafka as events and are intended for end-users for purposes such as billing or auditing.

Note: User metrics are not directly exposed via an API; consuming them requires a separate micro-service based on a Kafka Consumer to process the data.

The FPCScheduler is a proposed high-performance scheduler for OpenWhisk designed to address performance bottlenecks in the default ShardingPoolBalancer.

Key improvements include:

• Container-centric scheduling: Instead of scheduling requests to invokers, containers pull activation requests from dedicated action queues, maximizing container reuse.
• Distributed resource management: It allows schedulers to create containers on any invoker with sufficient resources, preventing the resource partitioning issues found in the standard controller-to-invoker model.
• Dedicated Action Queues: Each action has its own MemoryQueue to prevent interference between different actions.
• ETCD-backed coordination: Uses ETCD for transactions, health checks (via leases), and sharing cluster-wide information like scheduler/queue endpoints and throttling data.

For more advanced examples, complete applications, tutorials, and hands-on learning, use the following resources:

• OpenWhisk Community Resources: Includes samples, articles, and podcasts (github.com/apache/openwhisk-external-resources).
• OpenWhisk Workshop: A hands-on tutorial for learning OpenWhisk by doing (github.com/apache/openwhisk-workshop).

OpenWhisk is an event-driven compute platform (Serverless/FaaS) that executes code in response to events or direct invocations.

Key concepts include:

• Actions: Small snippets of code (JavaScript, Swift, etc.) or custom binary code in Docker containers. They are executed on-demand.
• Triggers: Channels for events (e.g., database changes, IoT sensor readings, HTTP requests). Triggers fire and cause actions to execute.
• Rules: Logic that maps a specific trigger to a specific action.
• Chains: A sequence of actions where the output of one action is passed as the input to the next.
• Packages: Bundles of Feeds (code that configures external event sources to fire triggers) and Actions (reusable logic).
• Feeds: Specialized code used to connect external services (like Cloudant or GitHub) to OpenWhisk triggers.