References
...
- Discussion point from BBS Meeting Minutes#2019.02.07
- Powerpoint file linked https://wiki.onap.org/download/attachments/8227019/ONAP%20Service%20Instance%20State%20Model%20to%20TMF%20638%20Mapping%20%281%29.pptx?version=1&modificationDate=1549533524000&api=v2
Attention To
Contributors
| Contributors | ||||||
|---|---|---|---|---|---|---|
|
Notes
- Slide 3 "shell object created in A&AI":
- note that mandatory fields and mandatory relationships cannot be enforced in AAI schema, if it is to allow empty shell objects as well as fully-formed objects
- those "mandatory" fields and relationships need to be enforced by the clients of AAI instead, meaning it could be distributed across many ONAP projects
- Slide 4 orchestration-status in Dublin:
- with the changes to the state names, how will the data migration be handled for operators upgrading to Dublin from previous releases?
- is there any forwards-compatibility or backwards-compatibility?
- Slide 5 service-instance schema in AAI:
- there are currently no substantive differences between Casablanca (v14) and Dublin (v15)
- Slides 7, 8, 10 mappings from TMF 638, TMF 641, ETSI SOL 005:
- would it be better to create a "state-mapping" class in AAI that can show explicitly the mapping to ONAP orchestration-status?
- the "state-mapping" object can be related to the service-instance object and queries can be performed using both the ONAP-native status or the external-standards-native status
- Slides 11 and 12 Slide 11 HSIA service updates to AAI:
- seems OK
- Slide 12 Nomadic ONT updates to AAI:
- seem OKred-boxes appear to be missing the update of ONT's attachment point?