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, to which the ciao configuration package interacts with. Supported back-ends are plain local file, etcd[WIP] and ZooKeeper[WIP]. 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 for it 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 upon reception of this piece of data. SSNTP clients that depends on cluster specific configuration data should wait for the scheduler to send it to them before initializing.
2. Accepting, validating and storing configuration changes from the ciao-controller
   • 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

#Configuration Data

#Storage Backends