POMBA Validation Rules

The POMBA Validation Service comes with a set of rules that verify the data provided from the supported context builders. The rules delivered are not exhaustive (refer to the POMBA Rules) but the architecture allows for operators to add their own rules or customize existing rules in order to fulfill their specific needs.

The rule sets are simply arbitrary files (of Groovy code) contained within project-specific directories that are read by the Validation Service on startup.

In ONAP, POMBA rules are delivered via the OOM project in default-rules.groovy.

The Rule Tester Utility can be used to test and debug new rules.

Update Rules

The structure and logic of the validation rules can be found here: https://wiki.onap.org/display/DW/Validation+Service.

The purpose of this page is to show how to add rules to a POMBA deployment.

Create Rule Code

The first step to adding a rule is figuring out what to validate.

Given the following event that's been assembled and published by context-aggregator:

{
  "event-header": {
    "entity-type": "poa-entity",
    "event-type": "POA-EVENT",
    ...
  },
  "entity": {
    "poa-event": { ... },
    "context-list": {
      "aai": {
        "service": {
          "name": "my-service-name",
          "type": "abc123-1"
        }
      }
      "sdc": {
        "service": {
          "name": "other-service-name",
          "type": "abc123-#?"
        }
      }
    }
  }
}


Let's create a rule to validate the service type.  We can assume that the rule will be executed with a single type, so we'll create a short groovy script to test the rule logic.

boolean validateServiceNameRule(String type) {
   // accept only lowercase letters, digits and dashes
   return type != null && type.matches("[a-z,0-9,-]*")
}

Define the Rule

After verifying that the groovy method works, the rule definition can be created.  On the target system, locate the rules directory for the POMBA event type (POA-EVENT).

$ cd ~/oom/kubernetes/pomba/charts/pomba-validation-service/resources/bundleconfig/etc/rules/poa-event
$ ls
default-rules.groovy
$


Add the new rule definition to any rule file (currently only default-rules.groovy exists).  Multiple rule files can exist, however a rule can only be defined once, then can subsequently be used multiple times.

Rule definitions look like the following code block.  Notice that only the content of the groovy method is in the validate section.  (For more examples, see Validation+Service#ValidationService-Examples)

rule {
  name        'validate-service-type'
  category    'INVALID_TYPE'
  description 'Invalid service type'
  errorText   'Invalid type - value contains invalid characters, only [a-z,0-9,-] accepted'
  severity    'MINOR'
  attributes  'type'
  validate    'type != null && type.matches("[a-z,0-9,-]*")'
}

Add useRule

Now add the useRule clause(s) in the validation section of all targeted entities.  Currently POMBA only has 1 entity defined for default rules (see entity definition here).

useRule contains 2 fields:

  • name: name of the newly created rule.
  • attributes: specifies the location of the attributes to be passed to the rule at runtime; it's a full JSON path, starting from the incoming event's entity section, see example event above.

Two useRules clauses are being added here to validate the service types from A&AI and SDNC.

entity {
  name 'POA-EVENT'
  indexing {
	indices 'default-rules'
  }
  validation {
    // AAI service type
	useRule {
	  name 'validate-service-type'
	  attributes 'context-list.aai.service.type'
	}
	// SDC service type
	useRule {
	  name 'validate-service-type'
	  attributes 'context-list.sdc.service.type'
	}
  }
}

Restart Validation

Validation loads all the rule files at startup, so the pod needs to be restarted.

Since helm is recommended to deploy POMBA, the deployment must be deleted and reinstalled.  (Note that helm upgrade --restart-pods can't be used to restart validation, there's an open helm defect for this)

$ helm list
NAME                    REVISION        UPDATED                         STATUS          CHART           NAMESPACE
demo2-pomba             1               Tue Feb 19 20:29:22 2019        DEPLOYED        pomba-4.0.0     onap
...
$ helm delete demo2-pomba --purge
$
$ cd ~/oom/kubernetes/pomba
$ helm install . --name demo2-pomba --namespace onap
...

Submit Updated Rules to OOM

Once the rule has been properly tested, submit the updated rules file in OOM's validation chart:

https://git.onap.org/oom/tree/kubernetes/pomba/charts/pomba-validation-service/resources/bundleconfig/etc/rules/poa-event

If a new rule file has been created, don't forget to update the chart's deployment.yaml.


  • No labels

3 Comments

  1. helm delete dev-pomba --purge

    cd ~/oom/kubernetes

    make pomba

    make onap

    helm deploy dev local/onap -f /root/oom/kubernetes/onap/resources/environments/public-cloud.yaml -f /root/integration-override.yaml --namespace onap  --verbose


    Do you  need to delete any data in dockerdata-nfs or make sure any pv/pvc's are deleted before the helm deploy ?

  2. No, I haven't come across a situation where deleting dockerdata-nfs was required.

  3. Brian, our testings how that we do not need to extra clean up of pvc when we use 'helm install' and 'helm delete'. However, 'helm undeploy' appears to leave some pvcs behind. I need to run 'kubectl -n onap delete pvc $pvc' name to clean up the PVCs before the same release name can be used for the next 'helm deploy'.