Page Comparison

...

Project Name: Distributed KV Store for configuration settings

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.
  
  

...

Pictorial representation of Distributed KV Store with consuming services:

API Reference for the KV store:

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.

...

• RESTful API to set/read/update the configuration settings,  leadership election and take/release distributed lock.
• Long poll for near instant configuration notifications.
• Client packages:
  • For configuration store,  both Java and Python have abstraction alrady over consul and hence there is no special service-level package is required.
  • Python and Java based client package to simplify leadership election and distirbuted locks. This package wraps various operations required to elect the leader. Also, this client package abstracts various operations required to create lock, take and release the lock.

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,  ideas can be taken from this project).

Key Project Facts:

Primary contact :  Srinivasa Addepalli,  Shashank Kumar Shankar

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.

Distributed KV Store Functionality Freeze Checklist:

Tracking Milestones:

https://

...

wiki.onap.org/

...

display/DW/Tracking+Milestones

API Reference:

https://git.onap.org/music/distributed-kv-store/tree/swagger.

...

For all completed Sprints, have Sprint Backlog Stories been marked as "Done" in Jira?

...

...

Are all tasks associated with the completed Sprint Backlog Stories been marked as "Done" in Jira?

...

Have all API projects dependencies been captured?

...

https://gerrit.onap.org/r/gitweb?p=music/distributed-kv-store.git;a=summary

...

For evidences, provide link(s) to Gerrit repos by providing the URL as shown in this example

Example

...

Not applicatible to Golang projects.

...

Guidance on Code Coverage and Static Code Analysis

Tools: Sonar

...

yaml

Testing and Integration:

The following type of tests are done in this release:

• Unit tests: Currently has around 50% unit test coverage as evidenced in the logs for the latest build: https://jenkins.onap.org/view/music/job/music-distributed-kv-store-master-merge-golang/lastBuild/consoleText
• Functional Test cases: Functional Tests run in CSIT tests.

Example test case: https://git.onap.org/music/distributed-kv-store/tree/src/dkv/api/

...

configHandlers_test.go

As an example (provided by Integration Team)

...

Goal is to ensure your project latest commits have not broken the build.

...

Generate Code Coverage Report of source code for Golang applications:

$ go test -coverprofile=coverage.out

$ go tool cover -html=coverage.out

Image Added