Configuration

#Cluster Configuration In order to run properly, typical clusters need to be provisioned with configuration data. Services URLs, credentials, backends and component properties, TLS certificates paths or services availability are only a few examples of configuration data that a cluster may need to access in order to operate at all.

In clusters where the software architecture is distributed and fragmented, the overall configuration data set is spread around many components over many different machines. Provisioning such clusters proves to be challenging and adds one more hurdle towards deployment and installation ease.

Ciao aims for being as simple to deploy and setup as possible and leverages its integrated architecture for building a minimal and centralized configuration framework.

#Design Goals The ciao configuration architecture design goals is two-fold:

1. Minimization: The complete configuration data set should be as small as possible.
2. Centralization: The configuration data should be provisioned in one single entity, on one single physical machine.

#Architecture Overview Ciao's cluster configuration is stored and fetched from a cluster specific storage back-end, with which the ciao configuration package interacts. Supported back-ends are plain local file, etcd[WIP] and ZooKeeper[WIP]. In order to configure a ciao cluster, one only needs to provision the configuration back-end with the right cluster configuration data. This data is then propagated to all ciao components by the ciao-scheduler.

The ciao-scheduler is the only component in a ciao cluster that interacts with the configuration back-end, by calling into the configuration package API. As a consequence it needs to be given a configuration backend URI through its -configuration-uri command line option. The default value is file:///etc/ciao/configuration.yaml.

The scheduler is responsible for 2 configuration tasks:

1. Propagating the configuration data to all its clients (Launchers, controllers, CNCI) for them to configure themselves as soon as they successfully connected to the scheduler.
   • SSNTP clients that depends on cluster specific configuration data should initialize themselves after successfully connecting to the scheduler.
   • The scheduler initially fetches the configuration data by calling configuration.ExtractBlob() and then adds it to all CONNECTED SSNTP frames it sends to successfully connected clients.
2. Accepting, validating and storing configuration changes from the ciao-controller
   • A cluster privileged operator may need to reconfigure the ciao cluster and should be able to update the configuration data.
   • The controller sends configuration updates through the CONFIGURE SSNTP command.
   • Invalid configuration data updates will not be propagated.
   • Valid configuration data updates will be stored by the configuration package in the configuration storage, and then propagated to all the scheduler clients.

##Configuration data propagation The configuration data is

#Configuration Data

#Storage Backends