Problem: Given an installed collector how to configure and run it

Solution: Store configuration values in a Consul instance (and secrets in a Vault instance), code a utility to read these values and supply them to the collector via its api.

Consul is a clusterable, disributable service that can act as a Key/Value store for configuraiton data. It is simple to set up and use and highly scalable. A Consul cluster will act as the centrally accessible store for various parts of the architecture as well as administrators to store and retrieve configuration. Consul would also represent the default storage layer for /wiki/spaces/RedboxHome/pages/2562776139 which will generate and hold our secrets (e.g. config values that are highly sensitive plus encryption keys). Consul also has its own UI as well as an API to be able to retrieve and update configuraiton values.

NOTE not ALL config values need to be accessible or in Consul - they would be generated by Kubernetes at orchestration time and passed to consuming services by kubernetes (or a static configuraiton would leverage Kubernetes internal dns so services would discover the other services via dns resolution. However we do need a centralised cofniguraiton repository to support the collector and media api configuration values.

On top of Consul we will need a mechanism to be able to pass these values to a collector - the RBR Centralised Configuration solution contains

Potential Reuse from RBR.CentralConfiguraiton:

There is a Recorder API stub project( RBR.CentralConfiguration.Stub.RecorderApi) - would save time having to develop against a real recorder BUT would need realignment with revised Collector API.
Project RBR.CentralConfiguration.RecorderClients could be taken and refactored/altered to work against the collector

Below are two links to API Yaml files, the first is a cut down rendition of the second which is the full classic recorder management API - where the collector version omits configuration points which are no longer relevant to the Collector architecture/

collector-api.yaml

recorder-api-2018-05-07_yaml.yaml

Tasks

Agree the best path for Collector API authentication - certificate authentication is desirable but it would be preferable for the collector NOT to have to make its own calls to the platform (e.g. with CSR to get a certificate). NB Our secrets generation and management system should be able to securely generate and provide a TLS certificate without needing a CSR - https://www.vaultproject.io/docs/secrets/pki/index.html)
Identify the best way to be able to test interaction with the Collector config API
Extract/transform/rewrite the code from Centralised Configuration that acts as a client of the Collector API - make this a reusable library, wrap in a console app (preferably RBVConfig or RBVCli) which allows being able to supply or query a collector from the command line (this will also need to be able to use the TLS cert from Vault).
Stand up Consul locally, familiariise, document, then ensure its container can be introduced into the devops cycle, get it clustered immediately
Define the initial configuration topology (e.g. key values such as "collectorgroups/<collector group id>/integration/sipserveraddress") and script out the ability to store these in consul - this could be as simple as replicating the url paths of the collector config api API
Code the utility/client library to be able to send values in logical groupings to the collectors
Integrate the control calls to restart/stop the collector

Browser not supported