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:
- 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
- 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.
- 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.
Gliffy | ||||
---|---|---|---|---|
|
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
Field Name | Description | |
---|---|---|
transaction-id | ||
service-instance-id | ||
model-version-id | ||
model-invariant-id | ||
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 cart carte flow
In case of Marco 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-cartcarte" 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
Field name | Description |
---|---|
flow-ind | A La carte or Macro flow indicator |
X-ONAP-Request-ID | Unique identifier of particular orchestration flow |
request-action | Action that was done by orchestration flow (create/activate/delete) |
service-instance{ service-instance-id, model-version-id |
, action } | ID of orchestrated service instance Unique identifier of the service model Action on the service instance level (create/update/delete) |
vnf-list{ vnf-id, model-version-id action } | List of VNFs which were changed during particular flow |
network-list { network-id, model-version-id, action }
| List of networks were changed during particular flow |
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