Single service design
Nested services feature is not currently supported as expected in SO. There is a workaround involving allotted resources, but the easiest solution for us is to go with a single service and everything else as a resource underneath it. This will not not impact our agreement with A&AI team for BBS. Everything that needs to be stored as metadata, can still be stored in the metadata section of the single CFS service.
Victor will have to handle the modeling changes so that in the service design, we can create one service with 2 VFs (Internet and Access Connectivity), 1 PNF (CPE-ONT), and the necessary virtual-links/cps.
Stavros will have to change the bbs-event-processor microservice implementation to reflect the fact that everything will now be under a single CFS service.
SDN-C will be creating everything under one service
PnP flow & E2E services
PnP flow part currently only works for normal services orchestration (services instantiated by VID). It is not working for E2E services orchestration (instantiated by an External API order request).
We need to check with Seshu how to handle it. It is a priority for BBS since we have based all of our flows in the PnP flow.
PRH will update PNF_ready internal event
PRH needs to send additional information coming in the PNF registration event (BBS use case specific) in the PNF_ready event (attachmentPoint, accessID, CVLAN, SVLAN)
Service-instance-related information
We need to provide further details for each piece of data we want to store under A&AI as part of a service instance, since SO handles service-related information.
Specifically
- Where this information comes from? Ext-API when ordering a service? CL event? What is the API used?
- Is the piece really needed to be in A&AI? (for example if only SDN-C uses it for resource controlling, then it could just come as input to its NBI and stored in MD-SAL)
- Which component is going to use it from A&AI?