kmohr-soprasteria
commented
2 years ago In todays meeting with Highstreet we discussed the following possiblities:
1. Extract OAS from controller The restconf interface can directly be extracted as an OAS (open api spec) from the controller:
- \<controller>/apicodc/explorer/index.html -> overview
- \<controller>/apidoc/openapi3/18/apis/mounts/1060 -> extract the OAS
Highstreet recommended not to use postprocessing for that (would lead to high efforts for adaptations in the future). The export is 100% open source. If changes are desired they can be requested via the official Jira.
Next step: compare the extracted OAS with other OAS
2. Implementation with no-sql database E.g. the control constructs could be loaded to a Mongo-db per device. This db already has a built-in rest API and filtering (can built indexes and filtering mechanisms on the fly) and supports e.g. xpath filtering. Note that the rest interface is different that than the one provided by the controller.
3. Is there something reusable available? There e.g. is the CPS (configuration & persistent storage) component which is under development by ONAP (so far only POC): https://docs.onap.org/projects/onap-cps/en/latest/overview.html Highstreet recommended not to use this.
The MWDI stores the complete Control Construct per device, but applications using that information should have the possibility to filter the data to only retrieve those information relevant to them.
It is desired that the MWDI works in the same way as the controller NBI (i.e. both can be used in the same way).
One possibility to achieve that would be to rebuild the complete restconf interface in the MWDI application. If done manually this would be lots of effort (and also prone to constant changes).