Improve DCAE PRH to handle Early PNF Registrations

Before editing please read instructions here.

 Description of Use Case / Requirement:

The PRH Handler is used in the 5G PNF Plug and Play use case.

https://docs.onap.org/projects/onap-integration/en/latest/docs_5g_pnf_pnp.html 

In 5G RAN, there can be multiple PNFs (RUs/DUs) inside a GNB service model. When this service is instantiated by SO Macro Flow, the PNFs must send the PNF Registration event to PRH in the same order as specified in the SO instantiation request, otherwise their registration event is dropped. 

This is because PRH is stateless, and when it receives a PNF Registration event , it checks if the PNF of the same source name as event has been registered by SO in AAI. If not found, it drops the event.

This presents a problem because in a GNB, DU/RUs cannot be enforced to start up in a particular order. If a PNF starts up and sends the event before SO registers the object in AAI, then SO never receives the PNF_READY event from PRH Handler. There should be a way that PRH caches/stores uncorrelated PNF registration events for a fixed amount of time, and retries the correlation during that period, so that if an event arrives early, before SO has registered the PNF in AAI, then PRH will retry the correlation after some time, so that the PNF event is eventually correlated, and SO is able to mark the PNF as active.

Two possible storage/caching mechanisms are described in the proposal, out which Option 2 (Kafka) is the preferred one. In order to implement Option 2, PRH should use native Kafka consumer and not the DMAAP Message Router. This change is also a requirement as described below.

• Design Option#2 using Kafka to persist/reprocess PNFRegistration topic is preferred
  • Following to be explored and incorporated in the target design.
    • Configurable option to enable/disable reprocessing of AAI failed lookup
    • Log and auto-commit (to remove failed entry) if older than x timeframe
    • DCAE SDK dmaap-client enhancement to support native kafka interface will be recommended. Depending on env/config/deployment properties, dmaap-client lib can serve a wrapper to switch between native kafka or MR REST api.

Owners (one of these should be the Assignee - use @ notation):

sangeeta.bellara 

Link to HLD/LLD (if any):

(attached)

Dependency Relationships with Other Projects:

Integration (Gating) and OOM 

Project (dcaegen2/services/prh) IMPACT: Code

• Impact Type: Code
• Company Engagement: DTAG
• Resources: 3
• Support Status: S
• Non-Functional Requirement Support: REQ-xxx, REQ-yyy

Integration Leads (use @ notation): 

 sangeeta.bellara