DMaaP DR API Updates.

See the Wiki page for details on the Data Router Changes:

5G - Bulk PM (Casablanca carry-over items)

Next Steps: Confirming API details.

For communication between SO and the CDS Blueprint Processor, a new API has been defined by CDS.

This U/C will use that new API to request configuration as the last step of the extended PNF workflow.

The API request and response format is defined in the following file: https://github.com/onap/ccsdk-apps/blob/master/ms/blueprintsprocessor/modules/commons/core/src/main/kotlin/org/onap/ccsdk/apps/blueprintsprocessor/core/api/data/ BlueprintProcessorData.kt

The blueprint processor allows requests to be sent using either plain HTTP with JSON or gRPC over HTTP/2. The client in SO will use the gRPC option.

This API doesn't have pre-defined actions and payloads. Instead they will be defined as part of U/C. For initial configuration (both VNF and PNF), the following actions will be used: config-assign and config-deploy. Payload format and contents have now been proposed for both actions.

API changes are needed. Config DB API, SDN-R. APIs for individual nodes record updates in Config DB. Bulk APIs for updating. API associated with SDN-C project. SON MS & Policy & OOF. Keep in sync with the corresponding Yang Model. OOF API: micro-service calls (optimization and passes data).

Freeze on API changes.

Next Steps: JSON swagger document being produced. (in progress)

Roll-back API. From SO to SDN-C (Controller). South-bound changes (captured in the Ansible Playbooks), impacting the external controller rather than the ONAP platform. Data pushed from API so south-bound APIs will have right data (in the payload).

Reusing LCM API (between SO to SDN-C) which already has the rollback in there.

The Rollback action is already specified in SDN-C. In the yang model for LCM.Yang (in CCSDK repository) file. Mandatory/generic header fields need to make them optional so that we can use them as a generic API to pass specific 5G info in the Payload. Currently Rollback function was not implemented yet (so no one is currently using this API).

Next Steps: API definition details in progress. Changing field options, and defining the payload.

New API for the Update Micro-service to SO (from the pnfUpdate event trigger) from Policy for the Reregistration Story. The "user" will be the BBS Micro-service U/C.

Next Steps: Ajay in DCAE has accepted this micro-service. Final details of the new service-update API is being defined in conjunction with SO project (Seshu).

API: New field for event publishing on pnfReady topic & pnfUpdate topic enhanced with additional fields as received in pnfRegistration event (a 1-to-1 copy). Was reviewed & agreed with BBS U/C team and change made in code (continuous integration system). Mar 14, 2019