STATUS - PROPOSED

OpenWhisk currently makes use of following mechanisms for configuration purpose. This document is meant to define a specific way for configuring OpenWhisk which can be used across various deployment options (bare metal via Ansible, Kubernetes, Mesos etc). This would  help in documenting the system config options in a uniform and simplified way

Configuration Modes

Direct Environment Variables

Some aspects are currently only configurable via environment variables like KAFKA_HOSTS , Metrics related flags etc. Use of such environment variables is only in few places

Typesafe Config Environment Variables

OpenWhisk core components now primarily use TypeSafe config mechanism in most places. This makes use of Human-Optimized Config Object Notation and provides a much better user friendly way to configure various components and is widely used by many libraries. This config has 2 parts

  1. Default shipped config - This config is is specified in application.conf files in various modules and captures the default configuration
  2. Config overrides - The default config can then be overridden via environment variables which follow specific convention. For e.g. to configure custom LogStoreProvider one should set an env variable CONFIG_whisk_spi_LogStoreProvider which then gets picked up and passed as jvm system property via transformEnvironment.sh script prior to launch of the jvm

Currently various ansible scripts use the above config override approach to modify the config as per system requirement. This mapping is at times tricky to get right and bit error prone (specially when setting list props). It would be better if we can directly pass in the config in typesafe config format. This would simplify managing the config in version control and also reusing the default config directly.

As part of #4039 support was added to pass typesafe config as base64 encoded env variable

Proposal

  1. Simplify passing configuration as typesafe config in our deployment scripts by making use of support added in #4039.
    1. ansible deployment - Add base templates which allow specifying the config and have then passed via OPENWHISK_ENCODED_CONFIG (#4309)
    2. kube deployment - TBD. The Helm charts needs to  be modified to make use of this
  2. Continue support for passing config as direct env variable following `CONFIG_xxx` convention

In public docs use the typesafe config approach to document the configuration examples to guide users on how to customize there Controller and Invoker deployments



  • No labels