Distributed KV Store

Project Name: Distributed KV Store

Project description:

Requirements:

• Currently, the configuration properties are stored in files. Each ONAP project maintains its settings in its own configuration files. Some of the challenges & requirements are :
  • Any update to the configuration settings require restart of the service.  This could lead to ONAP service unavailability for some time.  Requirement is that any configuration update should not lead to restart of ONAP services.
  • There is good amount of duplication information among the files in various ONAP projects.  Due to this, any change in this common information requires updating multiple files, which is error prone.
  • In future releases, ONAP is going to bring up services with multiple instances for high availability.  Any change in the configuration should be reflected in all service instances and also the configuration should be consistent in all instances.
  • Configuration store itself should be distributed for high availability of configuration data.
  • Configuration change should be easier for administrator - GUI facility to update the configuration.
• When there is a cluster of service instances, there can be a need for one of the instances to become a leader. That is, leader election could be a requirement for services.
• Yet times, some operations need to be atomically performed and hence there could be a requirement for distributed lock.
  
  

Distributed KV Store project is expected to address above requirements. It is expected to provide following functionality

• Centralization of  configuration
• Common configuration settings without duplication  
• Configuration update without the need for  restarting services
• GUI/CLI to update the configuration settings
• Auto notification of services when there is a configuration change.
• Reliable and distributed data storage. 
• Leadership selection
• Distributed lock 

Pictorial representation of Distributed KV Store with consuming services:

Scope:

Functionality :

• Ability to store configuration settings using reliable and distributed KV storage systems.
• Ability to provide leadership election among micro services.
• Ability to provide semaphore across service instances of ONAP services.
• Ability to modify the configuration settings
• Ability to inform active ONAP services of configuration changes.
• Ability to read the changed configuration 
• config-seed micro service to load default values of configuration settings, if settings are not present in the distributed KV storage.
• Bootstrap phase functionality where each service upon startup reads the configuration settings from distribtued KV storage.

Interface/API:

• RESTful API to set/read/update the configuration settings,  leadership election and take/release distributed lock.
• Long poll for near instant configuration notifications.

Architecture Alignment:

• How does this project fit into the rest of the ONAP Architecture?
  • Configuration-seed micro service is expcted to be a common service.
  • consul from MSB can be used as Distributed key store
  • Boot strap phase is expected to be part of each service 
• What other ONAP projects does this project depend on?
  • It does not depend on any existing ONAP projects.
• Are there dependencies with other open source projects?
  • Consul (http://consul.io).  Reasons for choosing consule:
    
    • Well maintained.
    • Used by many projects (e.g EdgexFoundry, vault project)
    • Good support for Java libraries (For Java based services, cfg4j is normally used to read the configuration. cfg4j has consul backend,  python-envconsul package is useful for python based services)
    • It is alredy being used by ONAP (as part of MSB) as service-registry and service-discovery.

Other Information:

• Distributed KV Store : https://github.com/hashicorp/consul
• configuration-seed : https://github.com/edgexfoundry/core-config-seed (But suggest to implement this in golang, but ideas can be taken from this project).

Key Project Facts:

Release Components Name:

Note: refer to existing project for details on how to fill out this table

Resources committed to the Release:

Note 1: No more than 5 committers per project. Balance the committers list and avoid members representing only one company.

Note 2: It is critical to complete all the information requested, that will help to fast forward the onboarding process.