Config DB 1.0 Interface (Dublin Impl.)

This page captures the original implementation of the original ConfigDB (PoC) as a preparation for introduction of the Configuration & Persistency Service (C&PS)

Resources

• Source Code: https://github.com/onap-oof-pci-poc/sdnc.git
• Swagger description of interface: https://github.com/onap-oof-pci-poc/sdnc/blob/master/ConfigDB/Dublin/SDNC_ConfigDB_API_v3.0.0.json

DB Details

The database used is MariaDb. 

DB Schema

CREATE SCHEMA IF NOT EXISTS `onap_demo` DEFAULT CHARACTER SET utf8 ;
USE `onap_demo` ;

-- -----------------------------------------------------
-- Table `onap_demo`.`cell`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `onap_demo`.`cell`(
  `cell_id` varchar(45) NOT NULL,
  `last_modifiedts` datetime(6) NOT NULL,
  `location` varchar(200) DEFAULT NULL,
  `network_id` varchar(45) NOT NULL,
  `notes` varchar(255) DEFAULT NULL,
  `pci_value` bigint(20) NOT NULL,
  `pnf_id` varchar(255) NOT NULL,
  PRIMARY KEY (`cell_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- -----------------------------------------------------
-- Table `onap_demo`.`cell_nbr_info`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `onap_demo`.`cell_nbr_info`(
  `cell_id` varchar(45) NOT NULL,
  `target_cell_id` varchar(45) NOT NULL,
  `ho` bit(1) NOT NULL,
  PRIMARY KEY (`cell_id`,`target_cell_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Suitability for extensions (v. 1.1)

• API and Schema not model driven but hard-coded for specific objects. Any new uses cases with new object will have to manually update the Schema and API
• Nothing will prevent anyone making those modifications but none of such changes will automatically be carried forward to C&PS (v. 2.0)

Proposed backward Compatibility

 No backward comparability is proposed for the following reasons:

1. The hard-coded nature of the current interface is a complete mismatch with the proposed model-driven generic interface. 
2. The class oriented pattern used in ConfigDB does not match the proposed Data Presentation using glorified maps
3. Some interface methods are badly named e.g. /api/sdnc-config-db/v3/insertData seems generic but actually can only handle a list of cells
4. The ConfigDB API is still extremely small and only supports 2 object types. The cost and effort to maintain backward incompatibility and limitations that will put on the proposed C&PS interface would be much higher then the once-of cost to update the single use-case with the new interface once established.

Alternative

At best the current interface could be re-wired to point to C&PS using a bespoke Yang-model to support the data (schema) it is currently using. Hoever it would be preferred to redesign in using the new generic interface and referring to the actual Yang model (fragments) that for the nodes for this use case.