...
- Functions:
- Provide catalog storage of models, model instances and execution logs
- provide catalog management operations, including synchronization, enable, disable, update, and delete etc.
- provide catalog relation management among different catalog objects
- Provide catalog relation management among different ONAP runtime components
- Provide catalog status and version management
- Provide search capacity for fast access across run-time catalog models and instances
- Provide API to let RT-components consume package, artifacts, and model instances
Note: using API to get package or Model instances is decided by the PTL of RT-components. - Provide portal for the Human Interface
- Provide S3P related capacity for RT-Catalog
Architecture Alignment:
- RT-Catalog architecture
- RT-Catalog Storage
Catalog models: storage of certified models
Catalog instances: which instances of which components uses which model in what time.
Model status, such as update, enable,disable,....
Model instance: model parsed results via model template and inputs
for example:
There is a service TOSCA template, which needs some inputs parameters.
When operator uses it to deploy A service with TOSCA template and input A, the parser will generate TOSCA instances A for A service.
When operator uses it to deploy B service with TOSCA template and input B, the parser will generate TOSCA instances B for B service.
Execution Logs: Log the transaction between other components, including important operation log of portal, SDC, and RT-components.
- What other ONAP projects does this project depend on?
- SDC(DT-Catalog)
- RT-Components(UI\SO\VFC\APPC\Policy\.......)
- Common service(MSB/DMaaP/Parser.....)
- How does this align with external standards/specifications?
- APIs/Interfaces - REST/PubSub
- Information/data models - Swagger JSON
- Are there dependencies with other open source projects?
- APIs/Interfaces - mysql, Django
- Integration Testing
- etc.
...