Page Comparison

In SDC  currently the normative types are maintained in two different places and they are not in sync.

• Cassandra - Zip is maintained in cassandra in sdcartifact.sdcschemafiles. Normative types are packed zip and saved in CS table during cs-init docker execution

           All types are packaged in output csar from cassandra

• Titan - All normative types are created in titan during sdc deployment in sdc-be-init docker execution by invoking internal REST APIs

           All types used and referred in SDC service creation are fetched from titan.

...

1. The normative  types in Titan and Cassandra may not be in sync.
2. New types cannot be added and synced to both DBs. This will create mismatch in created service and referred types in CSAR.

Proposed Solution:

Instead of managing normative types in SDC , introduce a different micro service which will maintain CRUD on all normative types. This micro service will be in its own gerrit repository different than in SDC. This will be single point for accessing normative and different applications like SDC can use it.

Current normative types are:

Normative Types

• Data
• Capability
• Relationship
• Interface
• Annotation
• Artifact
• Group
• Policy
• Nodes

Apart from CRUD APIs for all normatives , below are additional UCs which are supposed to be handled by micro service:

UC1

1. Get All - ability to get all normative types from an existing SDC Box in a way it is ready for "put' to another SDC Box
2. Put All - Ability to import a full package (based on #1 or other) into a clean SDC box

UC2

1. Get all types package from origin SDC Box
2. Compare the above with the target SDC types
3. User to decide on Action per type (Ignore new or Update)
4. Update Target Box based on actions

Changes/Impact on SDC

SDC Catalog now needs to fetch normative types from mirco service instead of titan/cassandra  All SDC Catalog flows using normative types will be impacted.

Create/Update of normative types done currently during SDC deployment also needs to be handled through micro service.

Solution:

1  Type Management Micro Service 

    It provides the ability to create and  update normatives using REST APIs. Also there are version APIs to create new version of normative and change status.

2  SDC

• Type Management Client - Using this SDC fetches data from type management by invoking its REST APIs
• NormativeHandler - Transforms the data fetched by type management client to SDC understandable model like DataTypeDefinition,etc. The handler caches the data fetched from type management per SDC request.
• Upload Normative internal APIs implementation is modified to load the normatives to type management using above handler instead of loading them to Janus.
• Normative type operation implementation is modified to fetch type using above handler.

• ApplicationDataTypeCache is no longer used. Instead data types are fetched on need basis from type management.

• sdc-cs-init no longer populates any SDC.zip to cassandra. CSAR packaging is also modified to fetch normative types from type management and pack in CSAR.
• Node Type Versioning and state transition is now done using type management.