The target: Parser as a service
The consensus reached: SDC Type fix A,B and C for Dublin
The problem: Providing the unified external APIs to consumer as a microservice
Next Steps: Research and Analysis the parser API list , then have depth discussion for API design in Paris
Meeting: 2 Jan 2019
Key point:
Meeting: 2 Jan 2019
Agenda:
- SDC Tosca type analysis
- ONAP generic parser
Attendee:
ATT: Anatoly, Ofir
CMCC: Lingli, Yan Yang
Huawei: Hui Deng, Shitao
ZTE: Maopeng, Xiaodong Shang
Minutes:
- SDC Tosca type analysis: https://wiki.onap.org/display/DW/SDC+Template+Type+Analysis
- Yan introduced the analysis background and the analysis result. Now the issues have been identified into four categories: A,B,C and D
- Anatoly said that it’s very easy to fix the issues identified and it’s not language things, it’s type level things. We just need replace type definition and type library or the normative definitions in SDC and see how it going. His understanding it should not cause any problem in runtime, but of course we need to validate the run time things.
- Lingli introduced the suggestions to fix the issues. And mentioned the minimal Goal for Dublin release is to fix the issues as we identified and typed A and B
- From Anatoly perspective, A B and C are all doable in Dublin, Further offline sync-up on detailed fix plan would be planned later.
- ONAP generic parser: ONAP Generic Tosca Parser
- Yan introduced the current tosca parser usage and also introduced the advantages and disadvantages of parser as an independent service.
- The requirements analyzed so far: SDC template types that need to be supported by parser; API calls from various consumers in run time
- Agreed in parser as a micro-service idea but stuck in implementation.
The problem encountered : it’s very hard to externalized into a service from the local library, Currently, our local TOSCA parsers return very complicated object graphs with hundreds of properties and references, and the depth of these graphs is not always predictable. But we cannot just create a naive API based on a simple 'parseTheDocument' request.
Another way would be to keep the resulting object graph on the server side, and then extend the service API with requests to navigate this graph. But this way still has some problems such as performance, state maintenance and other issues. We should consider and find a way how to return the complicated object from server side to the client side. - Maybe we can brainstorm this problem on the upcoming F2F in Paris.
Next steps:
- We need some concrete example to understand the impact or the problems, the next level discussion should be plan
Yan will provide the API list which we have collected from different modules in runtime leveraging SDC tosca-parser or NFV tosca-parser.
Anatoly can pick some of the specific ones that would cause the problems that described in the meeting - Anatoly will send his summary and suggestion offline
- Hui and Anatoly will help organize a specific parser discussion time slot