Instantiation Rules
POMBA audit reports are generated based on the rules that applied in the rules engine generating the violations. The following is an initial capture of rules
Rule | Data Sources | Attributes | Description | Category | Severity | Story | |
---|---|---|---|---|---|---|---|
1 | Attribute Comparison | A&AI, SDN-C, Network Discovery | All | This rule compares all attributes by the same name from different Context Builders and returns a violation if the fields do no match. This includes the case where the name is present by the value is null in one of the cases. It does not produce a violation if one of the Context Builders is missing an attribute. Note in Casablanca, this will be implemented in a non-generic way, and made more generic as a future work item | Attribute Mismatch | MAJOR? | |
2 | vnfc-type |
| Validate that each VNFC instance in AAI conforms VNFC type defined in SDC model | VNFC Consistency | ERROR | ||
3 | vnfc-count |
| Validate that for each VNFC node defined in SDC model there is at least one VNFC instance in AAI | VNFC Consistency | WARN | ||
4 | vf-module-type |
| Validate that each VF module instance in AAI conforms VF Module defined in SDC service model | VF Consistency | CRITICAL | ||
5 | nfc-naming-code |
| nfc-naming-code | Validate that nfc-naming-code exists and is populated in AAI VNFC instance | Expected Field Populated | CRITICAL | |
6 | data-dictionary-valid-value |
| All (assuming we can tell if not defined in dictionary) | Validates for a particular field that its value aligns to what is in the data dictionary | Invalid Value | ERROR | |
7 | vserver-vfmodule |
| If vfModule is present, I expect vserver/VMs to be present within this structure. | Coming soon to release near you | |||
8 | dataQuality | * | When there is a problem with the data provided to the validation engine (data missing due to system issues, etc), this rule shall raise violations. Longer term the plan is to report this in a separate dataQuality field. |
Note that Attribute Comparison in particular needs to check against the following, but should check everything it can
- Network Discovered attributes
- Existing AA&I and SDNC Comparisons for
- vnf-type
- vnf-name
- nf-naming-code
- Newly supported A&AI and SDNC attributes that align with those that have been network discovered
VNFInstance.vf-module[x].List of vservers VNFInstance.vf-module[x].vserver[x].id VNFInstance.vf-module[x].vserver[x].name VNFInstance.vf-module[x].vserver[x].inMaint VNFInstance.vf-module[x].vserver[x].pserver.hostname VNFInstance.vf-module[x].vserver[x].image.image-name VNFInstance.vf-module[x].vserver[x].prov-status and
Service.List of networks Network.id Network.name Network.isShared Network.uuid Network.invariantUUID
Deletion Rules
In the future, we will add additional rules to be able to audit that a service has been completely deleted. POMBA will likely require an input parameter on the audit initiation request to indicate whether someone wishes to run the instantiation rule set or the deletion rule sets.
Adding New Rules
The rules that POMBA runs are extensible and anyone can add new rules. Note this is in code currently, but can be done outside of the development cycle and manually applied if desired. Ideas for rules probably fall into two categories
- Validating design intent
- When designing ONAP features, you may wish to add rules to verify that the system is in the state you expect
- Automation of detecting errors found manually
- When using or testing the system, you may manually find a data integrity issue and wish to automate its detection in case it happens again