This document describes the intention of the flavor feature and how it is implemented. In order to allow application developers to select different environment for their applications, we need a way for them to specify this as parameters. The cluster administrator of the messaging service also need a way to control what parameters the developer can set, and be able to provide a controllable environment with resource limits.

There are two extreme approaches to this:

1. Expose all configuration variables to developers, such as disk size, broker image type, policies etc. This will expose a lot of details to the developer, and make it very flexible. It also makes it hard to maintain for the cluster administrator, and forces us to break the format once we need to modify or add changes to the addressing config.
2. Expose only a single variable, flavor, that can be changed by the application developer, and allow the cluster administrator to define the meaning of that variable. This allows the cluster administrator to have full control over the environment. The downside is that the developer is restricted by what the cluster administrator allows.

The ideal design lies somewhere in between these two extremes. The plan is to start out from the second approach, and gradually add 'standardized' configuration settings as requirements for them arise.

To achieve this, application configuration is kept along with the addressing configuration, while we define a new 'flavor' configuration that defines the set of flavors that are supported by the service. The term flavor may be replaced by something more descriptive, and once we identify the standardized configuration types, we can expose more concrete names.

Addressing config

{
    "myqueue": {
        "store_and_forward": true,
        "multicast": false,
        "flavor": "vanilla"
    },
    "secondqueue": {
        "store_and_forward": true,
        "multicast": false,
        "flavor": "chili"
    }
}

Flavor config

The flavor configuration would allow the cluster administrator to create configuration flavors that is supported on the openshift instance. The cluster administrator is responsible for creating the supported templates (though EnMasse will provide some default templates to use), and the supported flavor. A flavor is a specific set of configuration parameters for a given template. The flavor config format is shown below. The templateParameters can vary depending on the templateName. The supported parameters can be found by looking at the template definition.

{
    "vanilla": {
        "templateName": "queue-inmemory",
        "templateParameters": {
            "BROKER_IMAGE": "mybroker:latest"
        }
    },
    "chili": {
        "templateName": "queue-persisted",
        "tempalteParameters": {
            "STORAGE_CAPACITY": "8Gi"
        }
    }
}