...
The topology model is inspired by TAPI. It will use classes, relationships and constructs from TAPI together with additions that make it what it needs to be.
| draw.io Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
This diagram shows how the topology model can be integrated with the ONAP IM through use of the Domain class. There was some discussion of this. The general approach is valid. Specifics and thinking are still required, for example, is there a need to a TopologicalService as a class distinct from a Service?
Top level construct
I am missing a class that can be used by services that need to include flow domains, connectivity and endpoints. I see it as useful and flexible to allow this.
...
Makes sense, aligns with ONAP IM separation to date.
Agreed to remove the ServiceEndPoint and ServiceFlow/Intent from the sketch.
Intent
Intent is a wonderful new buzzword. It is only as good as the interpreter is. Eventually the intent needs to be translated into configuration of endpoints, connectivity and flow domains. Intent is also hierarchical, it will be evolved by layers of interpreters. Of course we need to keep the reference back to the intent for traceability (and possibly in scheduling). This can be achieved by having a simple hierarchical element that is referenced by the 'Resource'. So the participation of any resource in an 'intent' can be traced and interrogated regardless of the interpreter.
...