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
Attention To
@David Perez Caparros@Seshu Kumar Mudiganti@James Forsyth@Adrian OSullivan
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
Slide 11 HSIA service updates to AAI:
seems OK
Slide 12 Nomadic ONT updates to AAI:
red-boxes appear to be missing the update of ONT's attachment point?