POMBA Design Issues

SDNC API Mapping

[Need to add some content here around how we will approach the issue of mapping table for API call to service flow]

Integration with DCAE  

DCAE stores "fault data" in postgrepsql DB

POMBA would like to access that DB via APIs (currently identified as 'geolinks' api). Question: Is this API ATT specific or also in ONAP?

• Doug's comment: If data is present in fault table (is there a time factor to be considered here i.e how fresh is the data?) then that is indication that collector is configured but if not then that is not an indicator of an issue.  AGREE?

• Geora:   Agreed

Open Issues

• What API is available in ONAP/ECOMP and what data does it give us/not give us - currently i believe there MAY be an API into Vertica DB and we MAY be able to re-use geolinks API.  Action is with Geora (per Chesla).

• Is there any enrichment required in context builder to allow us to access the data?

Pluggable Data Dictionary

    TBF..

3 solution were brought up: 

1. Rule DSL will specify java method within VS. That method will implement the call to external system (DD) to pull the data and the result will be injected into the rule processing. This approach is valid when the same rule just need to use different / updated values to be compared with in the scope of the same rule, but it does not provide the way of modifying existing rule or adding new one 

2. Implement additional process that will run before validation , which will be responsible to update rules groovy file in the file system. Validation service will be enhanced to have a “smart watch” on the rules file changes and reload it in case of any change.  

3. Implement the mechanism of modifying rules on the fly inside the validation service and expose the interface so it can be called from outside. Updated rule can be stored in memory as well as in file system for persistency. 

Dynamic Rules 

POMBA should support the mechanism of separating rules from validation service code, thereby allowing changing the rules without a rebuild or restart of the validation service. The text of the message displayed for each violation will be kept separately to allow text change without touching the code

Audit Trigger

Manual Trigger

Rest API is exposed to any orchestration tool (VID,..)  

Manual request consists of the following attributes

Automated Trigger  

The audit process will be triggered by consuming "orchestration complete" event from message router which will be generated by Service Orchestrator.

There are two types of orchestration flow:

• Macro flows

•  A la carte flow

In case of Macro flow, the Service Orchestrator will produce "orchestration complete" event  when the workflow of service instance with all its resources is completed  In case of "A la-carte" flow, there are several workflows processed by SO, and SO may generate "orchestration complete" event at the end of each workflow request, which may represent only partial service instantiation process.

Orchestration Complete message published by SO into Message Router should include the following info

Open Issues

• Currently only talking with VID - other portals required?

• Is VID budgeted to implement 'audit initiate' button?

• What do we need to return to VID to make this useful?  eg 'success/fail', results, graphical view, report, etc

Authentication and Authorization

POMBA should be integrated with AAF.

POMBA clients (VID) will be using Basic Auth to authenticate themselves against AAF

POMBA will be using Basic Auth to pass the authentication for A&AI microservices 

In the future Basic Auth will be replaced by cert issued by AAF certificate manager