Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Introduction

Tosca lab has 2 main scripts:

  • model_create.py - to create tosca model artifacts from component spec
  • policy_create.py - to create policy type artifacts from component spec

This page concentrates on usage of policy_create.py

Script policy_create.py  creates data_type that can be used by policy_type.
In context of Closed Loop, policy type describes how to create microservice policy (maybe operation policy in future) in Clamp.
Policy types and Data types are extracted by Clamp from CSAR file created by SDC.

Control Loop Artifacts

CSAR package contains 3 artifacts required by Clamp to create closed loop:

  • DCEA_INVENTORY_BLUEPRINT - artifact describing how to deploy closed loop
  • policies.yml - contain policy types
  • data.yml - data types used by policy types (there is more of them inside it but those are not interesting for us)

Let's take a look what are dependencies between them:


To deploy* closed loop Clamp uses DCEA_INVENTORY_BLUEPRINT.
Each node that is deployed has to have specified it's policy type.
From Analytic Microservice perspective policy type is a scheme of how it's configuration should look like.
If node doesn't have specified policy type Clamp assumes it's default one onap.policy.monitoring.cdap.tca.hi.lo.app
Policy types described inside policies.yml can have sub-nodes. Those sub-nodes are data types. They're described inside artifact data.yml.


*It's simplification. Clamp requests DCAE to deploy microservice.

Tosca Lab policy create


Dublin constraint is that both data.yml and policies.yml are hardcoded and can't be changed/extended in runtime.

Script policy_create.py  is able to create new policy type and data type that could be add to policies.yml and data.yml.

How policy_create.py works:

Script policy_create.py requires single spec file. Example spec files and microservice onboarding flow is described here MicroServices Onboarding in ONAP.
Full microservice spec is really large JSON. To simplify I've created simple microservice_spec.json. This spec contains only fields required by policy_create.py to create new policy type.

This spec lacks field required by model_create.py to create tosca model. It's just for policies (but could be easily extended)


 Click here to expand microservice_spec.json
{
  "self": {
    "name": "my_custom_policy_type",
    "version": "0.1",
    "description": "This is basic spec creating policy type",
    "component_type": "cdap"
  },
  "parameters": {
    "app_preferences": [
      {
        "name": "testPolicyModel",
        "description": "test",
        "policy_editable": true,
        "policy_schema": [
          {
            "name": "primitiveExample",
            "description": "example of how to create primitive field in policy type",
            "type": "string"
          },
          {
            "name": "listExample",
            "description": "example of how to create list field in policy type",
            "type": "list",
            "entry_schema": [
              {
                "name": "primitive",
                "type": "string"
              }
            ]
          },
          {
            "name": "objectExample",
            "description": "example of how to create single object field in policy type",
            "type": "policy.data.objectExample",
            "entry_schema": [
              {
                "name": "primitive",
                "type": "string"
              },{
                "name": "primitiveInteger",
                "type": "integer"
              }
            ]
          }
        ]
      }
    ]
  }
}

To generate policy type out of it user has to run script policy_create.py using python. (This script is located inside <REPO>/sdc/dcae-d/tosca-lab/app/policy_create.py)

python policy_create.py -i ./microservice_spec.json -o ./output_policy.yaml

This command generate file output_policy.yaml.

 Click here to expand output_policy.yml
tosca_definitions_version: tosca_simple_yaml_1_0_0
data_types:
  policy.data.listExample:
    properties:
      primitive:
        type: string
  policy.data.objectExample:
    properties:
      primitive:
        type: string
      primitiveInteger:
        type: integer
  policy.data.testPolicyModel:
    properties:
      listExample:
        type: list
        description: example of how to create list field in policy type
        entry_schema:
          type: policy.data.listExample
      objectExample:
        type: policy.data.objectExample
        description: example of how to create single object field in policy type
        entry_schema:
          type: policy.data.objectExample
      primitiveExample:
        type: string
        description: example of how to create primitive field in policy type
node_types:
  policy.nodes.Root:
    derived_from: tosca.nodes.Root
    properties:
      policyDescription:
        required: false
        type: string
      policyName:
        required: true
        type: string
      policyScope:
        required: true
        type: string
      policyVersion:
        required: true
        type: string
  policy.nodes.my_custom_policy_type:
    derived_from: policy.nodes.Root
    properties:
      testPolicyModel:
        type: map
        description: test
        entry_schema:
          type: policy.data.testPolicyModel

Let's take a closer look

This file contains two main nodes

  • node_types - containing root node and policy.nodes.my_custom_policy_type. This node is actually a policy_type. In future it should derive from onap.policies.Monitoring instead of policy.nodes.Root
  • data_types - specifying data types (and sub-data types) used in node_type (policy_type)


  • No labels