Backward Compatibility with 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).

And discussed the backward compatibility of the new solution.

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

API Details

The REST-API is a hard-coded Spring FrameWork Controller: com.onap.configdb.web.controller.RanDBConfigController. Its operations are limited to

Create a list of cells
Add or Delete a Neighbor Cell
Query and Modify cell attributes specific to SON-Handler (PCI Usecase)

Swagger Editor Preview

DB Details

The database used is MariaDb.

DB Schema

onap_demo

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:

The hard-coded nature of the current interface is a complete mismatch with the proposed model-driven generic interface.
The class oriented pattern used in ConfigDB does not match the proposed Data Presentation using glorified maps
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
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 implementation could be re-wired to point to C&PS using a bespoke Yang-model to support the data (schema) it is currently using. However, it would be preferred to redesign it using the new generic interface and referring to the actual Yang model (fragments) that for the nodes for this use case.