Notes on ONAP Service Instance State Model to TMF 638 Mapping

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

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 updates to AAI:
  • seem OK